Flow management and flow modeling in network clouds

ABSTRACT

Assignment of network addresses and estimations of flow sizes associated with network nodes can be enhanced. Assignment management component (AMC) partitions a set of network addresses into subsets of network addresses associated with respective classes. For respective virtual machines (VMs), an estimator component estimates a flow size associated with a VM based on parameters associated with the VM. AMC classifies VMs based on threshold flow-size values and respective estimated flow sizes of VMs, and assigns VMs to respective sub-groups of VMs associated with respective subsets of network addresses based on respective classifications of VMs. AMC assigns an available network address of a subset of network addresses associated with a class to a VM of a sub-group associated with that class. Estimated flow sizes and performance metrics also are utilized to make determinations regarding VM placement, traffic management, load balancing, resource allocation, and orchestration in cloud networks.

TECHNICAL FIELD

The subject patent application is a continuation of, and claims priorityto, U.S. patent application Ser. No. 15/829,806, filed Dec. 1, 2017, andentitled “FLOW MANAGEMENT AND FLOW MODELING IN NETWORK CLOUDS,” theentirety of which application is hereby incorporated by referenceherein.

TECHNICAL FIELD

This disclosure relates generally to communications, e.g., to flowmanagement and flow modeling in network clouds.

BACKGROUND

In networking, a flow can be defined as a sequence of packets sharingcommon network identification attributes, which can be extracted frompacket header fields associated with the packets. The size (e.g.,volume) of a flow (e.g., origin-destination flow (ODF)) can be definedas the number of packets or bytes of a flow over a particular period oftime. For many networking applications, knowledge of flow sizes withregard to traffic being communicated in the network can be desirable fora number of reasons. For instance, flow size measurement and estimationcan be desirable in network monitoring, which can provide desired (e.g.,useful) information for different applications, including networkdesign, operation and management of the network, and/or security of thenetwork.

The above-described description is merely intended to provide acontextual overview relating to network communications, and is notintended to be exhaustive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of an example system that can enhancenetwork address assignments and flow-size estimations or determinationsassociated with nodes in a network, in accordance with various aspectsand embodiments of the disclosed subject matter.

FIG. 2 depicts a block diagram of an example virtual machine, inaccordance with various aspects and embodiments of the disclosed subjectmatter.

FIG. 3 presents a block diagram of an example assignment managementcomponent, in accordance with various aspects and embodiments of thedisclosed subject matter.

FIG. 4 depicts a block diagram of an example system that can facilitatedetermination of estimations of flow sizes associated with network nodesand use of the flow-size estimations to achieve various desiredobjectives in connection with networks, in accordance with variousaspects and embodiments of the disclosed subject matter.

FIG. 5 presents a flow chart of an example method that can enhanceInternet protocol (IP) address assignments and flow-size estimations ordeterminations associated with virtual machines in a network, inaccordance with various aspects and embodiments of the disclosed subjectmatter.

FIG. 6 depicts a flow chart of an example method that can enhance IPaddress assignments and flow-size estimations or determinationsassociated with virtual machines in a network to facilitate virtualmachine placement, traffic management and load balancing, resourceallocation, and/or orchestration in cloud networks, in accordance withvarious aspects and embodiments of the disclosed subject matter.

FIG. 7 is a schematic block diagram illustrating a suitable operatingenvironment.

FIG. 8 is a schematic block diagram of a sample-computing environment.

DETAILED DESCRIPTION

Various aspects of the disclosed subject matter are now described withreference to the drawings, wherein like reference numerals are used torefer to like elements throughout. In the following description, forpurposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of one or more aspects. It maybe evident, however, that such aspect(s) may be practiced without thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form in order to facilitate describing one ormore aspects.

In networking, a flow can be defined as a sequence of packets sharingcommon network identification attributes that can be extracted frompacket header fields. The size (e.g., volume) of a flow (e.g., anorigin-destination flow (ODF)) also can be defined as the number ofpackets or bytes of a flow over a particular period of time.Fine-grained flow-size measurement and estimation can be a significantproblem in network monitoring which can provide desired (e.g.,essential) information for different network applications, includingnetwork design, operation and management, and security.

Flow size estimation can be desirable (e.g., suitable, advantageous, orimportant) in many networking applications. There typically are two mainapproaches for flow size measurement and estimation. In one approach,direct flow size measurements, such as NetFlow and sFlow, can offerrelatively fine-grained flow size estimates. However, in large-scalenetworks it often can be inefficient and even infeasible to monitor eachand every flow due to the exploding volume of traffic and limitedmonitoring resources such as flow-table/Internet Protocol (IP)-tableentries, ternary content addressable memory (TCAM) entries, storagecapacity, and processing power. Accordingly, at least in large-scalenetworks, direct flow-size measurement techniques may not be scalabledue to the hard resource constraint of measurement resources.

In another approach, there are flow-size estimation techniques where thesize of flows can be estimated using a set of link-loads orflow-aggregated measurements. In networking, this problem is known asTraffic Matrix (TM) estimation. In this method, the ultimate accuracy offlow-size estimates can be a function of the characteristics of the flowsizes (e.g., the underlying probability distribution function of trafficflows), the characteristics of provided link-loads and flow-aggregatedmeasurements, and the estimation technique.

In software-defined networks (SDNs), user-defined flow-aggregatedmeasurements can be provided by installing flow-table/ternary contentaddressable memory (TCAM) rules on SDN-enabled switches and routers(e.g., using counters associated with TCAM/flow-table rules).Accordingly, a compressed set of informative flow-aggregatedmeasurements can be provided which can lead to a relatively moredesirable flow-size estimation accuracy via the application of networkinference techniques. Such a source of information can be transmittedfrom SDN-enabled devices (e.g., switches and routers supportingOpenFlow) to a centralized network controller. Consequently, using thesemeasurements and by applying different estimation techniques, the sizeof flows can be estimated at the controller. It is noted that otherauxiliary measurements (e.g., simple network management protocol (SNMP)link-loads) also can be available at the controller and can be used forflow-size estimation.

To provide user-defined flow-aggregated measurements, which can lead toa more desirable flow-size estimation accuracy, SDN users typically haveto be able to aggregate flows based on their needs to provide theinformative aggregated-flow measurements in such a way that incomingpackets can be uniquely classified by matching against flow-table/TCAMrules inside network devices. In fact, the characteristics offlow-aggregated measurements can totally, or at least primarily, dependon the constriction of flow-table or TCAM rules, which can be installedon the SDN devices across the network.

A significant part of a flow-table/TCAM entry in an SDN device can bethe IP-tuple <source IP, destination IP>. Therefore, the ability ofproviding user-defined flow-aggregated measurements mainly can beconstrained with the capability of combining different IP-tuples <sourceIP, destination IP> and forming a unique flow-table/TCAM entry. Thisproblem is known as a flow-aggregation feasibility constraint, whereinit can be quite difficult, if not impossible, to form an aggregatedIP-tuple <aggregated source IPs, aggregated destination IPs> that canrepresent a set of desirable IP tuples. This primarily can be due to themethod through which IPs are originally assigned to network nodes (e.g.,servers, computers, virtual machines). In networking, IP addresses canbe assigned to network nodes from a pool of IP addresses, typicallyusing dynamic host configuration protocol (DHCP), which can utilizedifferent strategies in assigning IP addresses (e.g., least recentlyused IP address). However, DHCP servers generally assign IPs withoutconsidering flow aggregation feasibility constraint.

Consequently, the capability of using a compressed set of informativeflow-aggregated measurements (e.g., through use of flow-table/TCAM rulesfor SDNs) can be significantly limited by the flow-aggregationfeasibility constraint where flows with different IP addresses cannot beaggregated, and constructing a unique flow-table/TCAM entry, thatrepresents a set of flows, can be quite difficult or impossible.

With particular regard to cloud communications, data communications canbe performed in cloud networks, for example, using cloud applications.Modeling, estimation, and prediction of flow size and performanceindicators, such as key performance indicators (KPIs), can be desirable(e.g., suitable, advantageous, or important) in cloud networkingapplications. As disclosed, the flow-aggregation feasibility constraintcan make flow size measurement and estimation quite difficult.

In that regard, techniques for enhancing the assignment of IP addressesto virtual machines (VMs), and estimating or determining flow sizes forVMs, are presented. In accordance with various aspects, the disclosedsubject matter can comprise a cloud management component (e.g., a cloudmanagement or controller component) that can control resources,services, etc., in a network (e.g., a cloud or communication network).The cloud management component can comprise an assignment managementcomponent that can resolve or mitigate the flow-aggregation feasibilityconstraint by assigning IP addresses to network nodes (e.g., VMs) in anintelligent way with respect to an application and based at least inpart on the characteristics (e.g., attributes or needs) of theapplication, as more fully described herein.

Also, as disclosed, in traditional networking applications, the flowsizes and performance indicators can be measured and estimated. However,in cloud networking, the VMs of a project/tenant can be instantiated bydefining a set of parameters which reflect the behavior of the trafficgenerated by VMs and affect the flow sizes and performance indicators ofVMs.

In accordance with various aspects of the disclosed subject matter, thecloud management component also can comprise an estimator component thatcan use these parameters (e.g., pre-defined parameters) of a VM todetermine (e.g., compute) a mathematical model for the flow size and/orother performance indicators of VMs. The parameters of a VM cancomprise, for example, the flavor size, number of virtual centralprocessing units (vCPUs) presented to the instance (e.g., to the VM),memory size (e.g., random access memory (RAM) size), disk space,communications bandwidth factor (e.g., receive and transmit (RXTX)factor), attached storage sizes, and/or another parameter(s). Theestimator component can effectively determine such a model usingdifferent regression and machine learning techniques, wherein theestimator component can use the model to estimate and predict the flowsize and other performance indicators of VMs. For instance, theestimator component can use such parameters of a VM to model and predictthe behavior of VMs in cloud networks. In accordance with variousembodiments, the estimator component and/or an evaluator component(e.g., of the assignment management component) can use the parameters ofVMs and the flow-size estimates, which can be determined based at leastin part on the parameters of VMs, to pre-evaluate some of theperformance metrics (e.g., KPIs, such as latency and/or data packetloss) of VMs in cloud networks, wherein the performance metrics can beused for a variety of applications (e.g., VM placement, cloudorchestration, traffic engineering, load balancing, and/orattack/anomaly detection), as more fully described herein.

As part of the enhanced assigning of IP addresses, the assignmentmanagement component can group respective VMs into respective groupsbased at least in part on the respective flow-size estimations ordeterminations. The respective groups can comprise, for example, a groupof VMs with a large flow size, a group of VMs with a medium flow size, agroup of VMs with a small flow size, and/or a group of VMs with a tinyflow size. A pool (e.g., set) of IP addresses can be available forassignment to the VMs. The assignment management component can assignrespective subsets of IP addresses from the pool of IP addresses to therespective groups of VMs. In some implementations, a subset of IPaddresses assigned to a group of VMs can be a subset of consecutive IPaddresses. The assignment management component can assign (e.g.,automatically (or manually) assign or select) an IP address to a VM of agroup from the subset of IP addresses assigned to such group to whichthat VM belongs. In assigning or selecting an IP address for a VM of agroup of VMs, the assignment management component can employ a desiredassignment procedure or algorithm, such as, for example, the firstavailable IP address in the subset of IP addresses associated with thegroup, the least used IP address in the subset of IP addressesassociated with the group, or another IP address assignment strategy oralgorithm.

By the assignment management component employing the enhanced assignmentof IP addresses to VMs, a set of desirably (e.g., most) informative andcompressed flow-aggregated measurements can be provided, which can leadto high flow-size estimation accuracy via applying, for example, networkinference techniques. This can be beneficial and of significance inlarge-scale networks and under hard resource constraints of limitedflow-table/TCAM sizes in SDN switches and routers. This disclosedsubject matter also can make network operation and management easier andfaster, as compared to other techniques for network operation andmanagement.

In cloud applications, with further regard to the flow size estimationsor determinations for VMs, the estimator component or another component(e.g., the evaluator component) of the disclosed subject matter canemploy such a model (e.g., the pre-evaluated metrics as modeled) fordifferent applications, such as, for example, VM placement, cloudorchestration, traffic engineering, load balancing, and attack/anomalydetection. Further, the model (e.g., the pre-evaluated metrics asmodeled) can make the applications more predictive and robust againstfuture changes in operation.

These and other aspects and embodiments of the disclosed subject matterwill now be described with respect to the drawings.

Referring now to the drawings, FIG. 1 illustrates a block diagram of anexample system 100 that can enhance network address assignments (e.g.,Internet Protocol (IP) address or media access control (MAC) addressassignments) and flow-size estimations or determinations associated withnodes (e.g., virtual machines (VMs)) in a network (e.g., a cloud orcommunication network), in accordance with various aspects andembodiments of the disclosed subject matter. The system 100 can comprisea cloud management component 102 (e.g., cloud management or controllercomponent) that can control the use of resources, services, etc., in anetwork (e.g., a cloud or communication network). The resources cancomprise, for example, computing resources, storage resources, data ordatabase resources, network resources, IP addresses, MAC addresses,and/or other resources that can be part of or associated with thecommunication network.

In accordance with various embodiments, the cloud management component102 can comprise a compute component 104 that can provide computingresources and services, and/or can facilitate provisioning and managingVMs. The compute component 104 can provide scalable and on-demand accessto the computing resources, including VMs, servers, and/or containers.In some embodiments, the compute component 104 can be or can compriseOpenStack Nova, although, in other embodiments, a different type(s) ofcomputing resource(s) associated with a cloud platform other thanOpenStack can be employed by the compute component 104.

The cloud management component 102 also can include a storage component106 that can provide storage resources (e.g., memory) and services. Thestorage component 106 can provide scalable access to the storageresources. Various types of data, including VMs, data utilized by VMs,user data, and/or other data, can be stored in and accessed from thestorage component 106. In accordance with various embodiments, thestorage component 106 can be or can comprise OpenStack Cinder (e.g., forblock storage) and/or Swift (e.g., for object storage). In otherembodiments, a different type(s) of storage resource(s) associated witha cloud platform other than OpenStack can be employed by the storagecomponent 106.

The cloud management component 102 further can comprise one or moreother types of resource components, such as a database component 108that can provide database resources and services. The database component108 can provide scalable access to the database resources, which caninclude relational and/or non-relational database engines, databases,and/or task performance and/or management. The database component 108can perform and/or can enable the provisioning and/or managing of one ormore database instances, as desired. In some embodiments, the databasecomponent 108 can be or can comprise OpenStack Trove. In otherembodiments, a different type(s) of database resource(s) associated witha cloud platform other than OpenStack can be employed by the databasecomponent 108.

The cloud management component 102 also can include a network component110 that can provide networking resources and services to facilitatecreating a desired network(s), network topologies, and/or networkpolicies (e.g., in the cloud). The network component 110 can providescalable networking, access to the networking resources, and/or taskperformance and/or management. In some embodiments, the networkcomponent 110 can be or can comprise OpenStack Neutron, which cancomprise a cloud networking controller and networking-as-a-service(NaaS) project within the OpenStack cloud network environment. In otherembodiments, a different type(s) of network resource(s) associated witha cloud platform other than OpenStack can be employed by the networkcomponent 110. The network component 110 (e.g., Neutron or other networkresource(s)) can comprise application program interfaces (APIs),plug-ins, components, authentication and authorization control protocolsand components, etc., that can facilitate interoperability of networkdevices and network-related technologies in a cloud network environment.

The network component 110 can be associated with (e.g., communicativelyconnected to) the compute component 104, the storage component 106, andthe one or more other types of components, including the databasecomponent 108, to facilitate providing one or more devices (e.g.,communication devices), which can be associated with the networkcomponent 110, access to the respective resources and/or services of orassociated with the compute component 104, the storage component 106,and the one or more other types of components (e.g., database component108).

The network component 110 can be associated with (e.g., communicativelyconnected to) a communication network 112 that can facilitatecommunications between the network component 110 and associatedresources of the compute component 104, the storage component 106, andthe one or more other types of components (e.g., database component 108)and devices, such as, for example, device 114, device 116, and device118, associated with (e.g., communicatively connected to) thecommunication network 112. The respective devices (e.g., 114, 116,and/or 118) can be a communication device that can communicate with thecommunication network 112 and associated devices or components via awireline or wireless communication connection with the communicationnetwork 112. The devices (e.g., 114, 116, and/or 118) can be, forexample, a mobile phone (e.g., a wireless or cellular phone), a computer(e.g., a desktop or laptop computer), an electronic notebook, anelectronic pad or tablet, an electronic gaming device, a personaldigital assistant (PDA), a set-top box, or other type of communicationdevice that can operate and communicate in a communication networkenvironment of the communication network 112 of the system 100.

The communication network 112 can comprise an overlay/underlay networkcomponent 120 that can facilitate communication of traffic between thedevices (e.g., 114, 116, and/or 118) and the network component 110 andassociated components (e.g., compute component 104, storage component106, database component 108) and resources and/or services of the cloudmanagement component 102 as well as between the respective devices(e.g., 114, 116, and/or 118). The overlay/underlay network component 120can comprise an underlay network that can comprise the physicalinfrastructure of the communication network 112, wherein the physicalinfrastructure can comprise the physical components, such as switches,routers, interfaces, controllers, nodes, etc., that can be arranged andconfigured in relation to each other to form the underlay network and tofacilitate communication of traffic between devices in the communicationnetwork 112. The underlay network can communicate data packets, and canmanage or facilitate management of the communication of data packets,across networks, or portions thereof, of the communication network 112.The overlay/underlay network component 120 also can include the overlaynetwork that can be a virtual network that can comprise one or morenetwork overlays that can be associated with (e.g., communicativelyconnected to) the physical network of the underlay network and canoperate on top of the physical network of the underlay network. Networkoverlays can employ techniques of using software virtualization tocreate the one of more additional network overlays that can be overlaidon the physical network of the underlay network.

The overlay/underlay network component 120 can comprise, for example,routers, such as routers 122, 124, 126, and 128, as well as othernetwork-related components (e.g., switches, interfaces, controllers,and/or nodes, . . . (not shown in FIG. 1)) that can be associatedtherewith. The respective routers (e.g., routers 122, 124, 126, and/or128) can be associated with (e.g., communicatively connected to)respective VMs, such as, for example, VMs 130, 132, and 134). It is tobe appreciated and understood that, in accordance with variousembodiments, the number of routers of the system 100 can be four, morethan four, or less than four. It also is to be appreciated andunderstood that, in accordance with various embodiments, the number ofVMs of the system 100 can be three, more than three, or less than three.

Referring briefly to FIG. 2 (along with FIG. 1), FIG. 2 depicts a blockdiagram of an example VM 200, in accordance with various aspects andembodiments of the disclosed subject matter. The VMs 130, 132, and/or134 of FIG. 1 can be the same as or similar to the VM 200 of FIG. 2. TheVM 200 can emulate or function as a real physical machine (e.g.,physical computer or server), and can be employed as a substitute for,and can be utilized in place of, the real physical machine. The VM 200can comprise an operating system 202 that can be executed by the VM 200to perform operations, manage hardware and/or software resources, and/orprovide services and functionality for programs or routines of orassociated with the VM 200. The operating system 202 also can act as anintermediary between programs and hardware resources of or associatedwith the VM 200. The operating system 202 can have a desired structure(e.g., can have a desired architecture) and functionality that can besuitable for the purposes for which the VM 200 is to be used.

The VM 200 also can comprise or be associated with a virtualized networkinterface card (vNIC) component 204 that can be utilized by the VM 200as a network interface to interface with the communication network 112,including, for example, the underlay network of the overlay/underlaynetwork component 120. The vNIC component 202 can emulate or functionas, and can be designed and configured based at least in part on, a realphysical network interface card (NIC), and the vNIC component 204 can beemployed as a substitute for, and can be utilized in place of, the realNIC. For instance, the vNIC component 204 can be the network interfacecontroller for the host (e.g., VM 200) in a same or similar way that aNIC can be a physical network interface controller for a host. While onevNIC component 204 is depicted in FIG. 2, in some embodiments, the VM200 can comprise more than one vNIC component 204.

The vNIC component 204 can have a MAC address 206 (e.g., a MAC addressunique to that vNIC component 204) assigned to it (e.g., by theassignment management component 136 or another component of orassociated with the system 100). The MAC address 206 can be a uniqueidentifier that can be assigned to the vNIC component 204 to facilitateidentification of the vNIC component 204 and facilitate datacommunications between the vNIC component 204 and other components ordevices associated with the communication network 112. In someimplementations, the MAC address 206 can be assigned to the vNICcomponent 204 (e.g., by the assignment management component 136) usingthe enhanced network address techniques and algorithms of the disclosedsubject matter, as more fully described herein.

The VM 200 also can have an IP address 208 assigned to it and/or thevNIC component 204 (e.g., by the assignment management component 136),wherein the IP address 208 can be assigned to the VM 200 and/or vNICcomponent 204 using the enhanced network address techniques andalgorithms of the disclosed subject matter, as more fully describedherein. The IP address can be used to identify or label the VM 200 (orvNIC component 204), so that other components or devices associated withthe communication network 112 can identify the VM 200 (or vNIC component204). The IP address also can be used to facilitate location addressingto facilitate identifying where the VM 200 resides in relation to otherhosts, components, or devices associated with the communication network112.

With further regard to FIG. 1, in some embodiments, the disclosedsubject matter can enhance assignment of network addresses (e.g., IPaddresses or MAC addresses) to network nodes (e.g., VMs) of orassociated with the overlay/underlay network component 120 based atleast in part on flow sizes of the network nodes, as more fullydescribed herein. In other embodiments, the disclosed subject matter canenhance the accuracy of flow-size estimates associated with networknodes (e.g., VMs, such as VMs 130, 132, 134, . . .) of or associatedwith the overlay/underlay network component 120, as more fully describedherein. It is to be appreciated and understood that, in addition to VMsbeing nodes (e.g., network nodes), nodes can be or can comprise servers,computers, or other components or devices of or associated with theoverlay/underlay network component 120.

It is to be appreciated and understood that, while the disclosed subjectmatter often refers to VMs, the various aspects, techniques, andprinciples of the disclosed subject matter also can be applicable toother types of nodes (e.g., network nodes) of or associated with theoverlay/underlay network component 120. Also, it is to be appreciatedand understood that, while the disclosed subject matter often refers toIP addresses, the various aspects, techniques, and principles of thedisclosed subject matter also can be applicable to other types ofnetwork addresses (e.g., MAC addresses) of or associated with theoverlay/underlay network component 120.

In accordance with various aspects and embodiments, the networkcomponent 110 can comprise an assignment management component 136 (e.g.,an intelligent IP assignment agent (IIPAA)) that can desirably assignrespective network addresses (e.g., IP addresses or MAC addresses) tonetwork nodes (e.g., VMs, such VMs 130, 132, 134, . . .) based at leastin part on the respective volumes of traffic being handled by (e.g.,respective flow sizes associated with) the respective network nodes, inaccordance with defined assignment criteria. With regard to flow-sizeestimation, aggregating flows with similar sizes or volumes (e.g.,similar statistical behavior or characteristics) can significantlyimprove the accuracy of flow-size estimates of nodes (e.g., VMs that areor are associated with nodes).

The assignment management component 136, by assigning respective networkaddresses to network nodes based at least in part on the respective flowsizes associated with the respective network nodes, can significantlyimprove flow-size estimation accuracy and/or can significantly reducethe number of flow-table/TCAM rules employed, which can be a significantand advantageous factor due to the hard resource constraints of limitedflow-table/TCAM sizes in SDN switches (e.g., SDN-enabled orSDN-compatible switches). The flow-table/TCAM rules can be utilized by,for example, the network controller component 138 of the networkcomponent 110 and/or network-related devices or components (e.g., SDNswitches or other SDN network-related devices) of the overlay/underlaynetwork component 120 to route traffic (e.g., data packets) andfacilitate communications (e.g., communication of the traffic) in thecommunication network 112.

In practice, the flexibility for assigning IP addresses can berelatively low in traditional networks, and it can be difficult toestimate, in advance, the size of traffic handling by a node, which canrepresent the inbound and outbound flow-size of the node. The disclosedsubject matter can efficiently address such issues in cloud computingnetworks where SDN can be employed as a technology for virtualizingnetworks among multiple tenants. In accordance with various aspects ofthe disclosed subject matter, in cloud computing environments, there canbe a relatively higher flexibility to assign IP addresses to VMs (e.g.,130, 132, 134, . . . ) from a pool of IP addresses (e.g., private IPaddresses) that can be allocated to a particular project or tenant. Theassignment management component 136 can leverage such flexibility inassigning IP addresses to VMs to facilitate enhancing the assignment ofIP addresses to VMs, as more fully described herein.

In some embodiments, the assignment management component 136 cancomprise an estimator component 140 that can estimate, determine, and/ormeasure flow sizes (e.g., traffic volumes) associated with network nodes(e.g., VMs, such as VMs 130, 132, 134, . . . ). For instance, for anetwork node(s) (e.g., for each of one or more network nodes), theestimator component 140 can estimate (e.g., can determine or calculatean estimation of) the traffic volume handling by a network node (e.g., aVM), which can represent the size of the flow associated with thenetwork node, based at least in part on (e.g., as a function of) defined(e.g., defined or predefined) parameters associated with the networknode. The defined parameters associated with the network node cancomprise, for example, the parameters of the flavor of the network node(e.g., flavor size of the VM, number of virtual central processing units(vCPUs) presented to the instance or VM, memory size associated with theVM, ephemeral disk space associated with the VM, and/or communicationsbandwidth factor associated with the VM), the type and volume ofattached storages to the network node, and/or the type or size of adatabase (DB) associated to the network node.

The communications bandwidth factor can be, for example, a receive andtransmit (RXTX) factor that can define the network capacity of aninstance and/or can represent the aggregate outbound bandwidth acrossall attached network interfaces. An RXTX factor, for example, can be ascaling factor that can enable servers to have a different bandwidthcapacity than the bandwidth capacity defined in the network to which theservers are attached. The RXTX factor can be multiplied by the RXTX baseproperty of the network, wherein the default RXTX factor can be 1.0(e.g., the same as the network to which the servers are attached), andsuch factor can be adjusted to be greater than 1.0 or less than 1.0.

Flavors of a VM (e.g., VM 130) can define, for example, a number ofparameters, such as parameters relating to the computing, memory, and/orstorage capacity of computing instances or VMs. The various parameters,as selected by a user, can enable the user to have a choice with regardto the type and/or configuration of the VM that the user would like torun, similar to how a user can select a type of physical server. Forinstance, a flavor of a VM can be an available hardware configurationfor a server, and can define the size of a VM (e.g., virtual server)that can be launched in the communication network 112 (e.g., launched inthe overlay network of the overlay/underlay network component 120).

In determining network address assignments, the assignment managementcomponent 136 can operate on a reasonable assumption that, for example,a VM (e.g., VM 130) with a larger flavor-size and a higher RXTX factor,can have heavier traffic and a larger flow size as compared to anotherVM (e.g., VM 132) with a relatively smaller flavor-size and a relativelylower RXTX factor. In some implementations, the assignment managementcomponent 136 can access and utilize other information from otherservices (e.g., other information from the database services provided bythe database component 108) to facilitate desirably determining andassigning IP addresses to VMs (e.g., 130, 132, 134, . . . ).

As disclosed herein, the assignment management component 136 can utilizeinformation provided by other services to desirably (e.g., efficiently,suitably, or optimally) allocate and assign network addresses (e.g., IPaddresses) to VMs (e.g., 130, 132, 134, . . . ), wherein the otherservices can comprise, for example, computing services from the computecomponent 104, storage services from the storage component 106, and/orinformation or database services from the database component 108. Asmore fully described herein, with regard to a pool (e.g., set) of IPaddresses that can be associated with a project, the assignmentmanagement component 136 can partition the pool of IP addresses into adesired number of groups (e.g., sub-groups or subsets) of IP addresses,based at least in part on the application(s) and/or project (e.g., therequirements or specifications of the application(s) and/or project), inaccordance with the defined assignment criteria.

Each sub-group of IP addresses can comprise a respective number of IPaddresses that can be different from or same as the respective numbersof IP addresses of the other sub-groups of IP addresses. The IPaddresses in a sub-group of IP addresses can be consecutive IP addresses(e.g., IP addresses can be in consecutive order in relation to eachother). The assignment management component 136 also can associate(e.g., can assign) respective sub-groups of IP addresses respectivenames or indexes (e.g., large, medium, small, and/or tiny, . . . ),based at least in part on the number of different sub-groups of IPaddresses and the respective types of (e.g., respective range of flowsizes associated with) the respective sub-groups of IP addresses, inaccordance with the defined assignment criteria.

For a given VM (e.g., 130) of one or more VMs (e.g., 130, 132, and/or134, . . . ) associated with the project, the estimator component 140can apply a function f on a set of defined parameters of the VM (e.g.,flavor size, attached storage size, and/or RXTX factor, associated withthe VM) to generate an output that can be an estimate of the flow sizeof the VM (e.g., an estimate of a potential flow size of the VM) and theparticular name or index of the sub-group of IP addresses to which theVM belongs, wherein the function f can be and can operate, as more fullydescribed herein.

The assignment management component 136 can assign (e.g., canautomatically or manually select and/or assign) an IP from a list ofavailable IP addresses of the sub-group of IP addresses associated withthe particular name or index (e.g., the group to which the VM belongs),based at least in part on a defined assignment procedure or algorithm,in accordance with the defined assignment criteria. In accordance withvarious aspects or embodiments, the defined assignment procedure oralgorithm can be the first available IP address of the sub-group of IPaddresses, or can be the least used IP address of the sub-group of IPaddresses, or can be another desired assignment procedure or algorithm.In accordance with the applicable assignment procedure or algorithm, theassignment management component 136 can assign the first available IPaddress of the sub-group, the least used (and available) IP address ofthe sub-group, or another available IP address of the sub-group (inaccordance with another assignment procedure or algorithm) to the VM.

The assignment management component 136 (or another component of thesystem 100) also can determine a desirable set ofIP-table/flow-table/TCAM rules (e.g., a compressed set having a reducednumber of such rules) that can be employed with regard to networkdevices (e.g., SDN switches or other SDN devices), based at least inpart on the respective flow-size estimates of respective VMs and/or viaapplication of network inference techniques or algorithms, as more fullydescribed herein. The desirable set of IP-table/flow-table/TCAM rulescan be a compressed or reduced set of IP-table/flow-table/TCAM rulesthat can provide desirably informative (e.g., suitably informative,optimally informative, or most informative) flow-aggregated measurementsfor flow-size estimation associated with VMs (e.g., 130, 132, 134, . . .).

The network controller component 138 (e.g., SDN controller) can receivethe desirable (e.g., compressed or reduced) set ofIP-table/flow-table/TCAM rules from the assignment management component136, or the network controller component 138 can identify such rules,and access and retrieve, such rules from a storage component (e.g.,storage component 106) or other data source. The network controllercomponent 138 can install (e.g., proactively, actively, automatically,or dynamically install) the desirable set of IP-table/flow-table/TCAMrules on the SDN network devices (e.g., SDN-enabled or SDN-compatiblenetwork devices, such as SDN-enabled or SDN-compatible switches).

The following disclosed subject matter can further illustrate variousaspects and embodiments of the enhanced IP assignment techniques,process, and algorithm for assigning IP addresses in cloud computingenvironments. Referring to FIG. 3 (along with FIG. 1), FIG. 3illustrates a block diagram of an example assignment managementcomponent 136, in accordance with various aspects and embodiments of thedisclosed subject matter. The assignment management component 136 cancomprise the estimator component 140, which can perform tasks and canfunction as more fully described herein.

To facilitate illustrating various aspects and embodiments, consider aset or a pool of IP addresses that can be denoted by I. The assignmentmanagement component 136 can comprise a partition component 302 that canpartition the set (e.g., pool) of IP addresses into L groups (e.g., Lsub-groups) of respective IP addresses. In some embodiments, thepartition component 302 can partition the set of IP addresses into Lsub-groups of respective IP addresses, wherein the respective sub-groupscan comprise respective subsets of consecutive IP addresses that cancomprise respective numbers of IP addresses. These L sub-groups can bedenoted by I₁ up through I_(L) (e.g., I₁, . . . , I_(L)), wherein L canbe virtually any desired number, and wherein each sub-group also canalso have a desired name or index, such as, for example, large, medium,small, and/or tiny (e.g., in this case where L=4). While this exampleinvolves four sub-groups (e.g., with L=4), the disclosed subject mattercan employ a desired number of sub-groups that can be less than four,four, or greater than four, for example, as specified by the definedassignment criteria.

In an example case, I=∪_(J=1) ^(L) I_(j) where I_(i)∩I_(j)=Øfor i,j∈{1,.. . , L} (e.g., {1 up through L}) and i≠j. It is noted that the numberof IP addresses in each sub-group can be different (or the same), thatis, the cardinality of set I_(i) (denoted by |I_(i)|) for all i∈S={1, .. . , L} are not necessary equal. The partitioning of the set of IPaddresses by the partition component 302 can depend, at least in part,on the application(s) (e.g., associated with the project) and therespective specifications or requirements of the application(s). Forexample, based at least in part on the specifications or requirements ofthe application, with I=254, for a pool of 254 IP addresses (e.g.,subnet 10.0.0.0/24, excluding 10.0.0.0 and 10.0.0.255), the partitioncomponent 302 can partition of the pool of 254 IP addresses, and canassign 16 consecutive IP addresses to VMs determined to have a largeflavor size (in the sub-group named or indexed as large), 32 consecutiveIP addresses to VMs determined to have a medium flavor size (in thesub-group named or indexes as large), 64 consecutive IP addresses to VMsdetermined to have a small flavor size (in the sub-group named orindexed as small), and 142 consecutive IPs to VMs determined to have atiny flavor size (in the sub-group named or indexed as tiny).

In some implementations, the assignment management component 136 cancomprise an analyzer component 304 that can analyze information relatingto the specifications and/or requirements of the application tofacilitate determining the number (e.g., L=4) of sub-groups of VMs toemploy, the respective numbers of IP addresses to assign to therespective sub-groups, the respective ranges or threshold values (e.g.,threshold flow-size values) to assign to the respective sub-groups andassociated names or indexes, etc. The partition component 302 canpartition the set of IP addresses into the respective sub-groups of IPaddresses, assigning the respective numbers of IP addresses (e.g.,consecutive IP addresses) to the respective sub-groups of IP addresses,based at least in part on the results of the analysis by the analyzercomponent 304.

The analyzer component 304 also can operate in conjunction with theestimator component 140 to analyze one or more parameters orcharacteristics associated with a VM (e.g., VM 130) to facilitatedetermining an estimated flow size associated with the VM, as more fullydescribed herein. The estimator component 140, applying a desiredfunction (e.g., function f), can facilitate determining the estimatedflow size associated with the VM, based at least in part on the analysisresults obtained (e.g., by the analyzer component 304) from the analysisof the one or more parameters or characteristics associated with the VMand the function applied to the one or more parameters orcharacteristics associated with the VM (e.g., the function applied tothe analysis results relating to the one or more parameters orcharacteristics).

The assignment management component 136 also can include a functioncomponent 306 that can comprise one or more functions, and facilitatethe application of one or more of the functions to data to determine orgenerate an output (e.g., output data results) of the function(s). Thefunction component 136 can be employed to facilitate determiningrespective estimations of flow sizes associated with VMs (e.g., 130,132, 134, . . . ), based at least in part on respective parameters orcharacteristics associated with the VMs, and determining respectiveclassifications for respective flow-size estimations and associated VMsbased at least in part on the respective flow-size estimations of therespective VMs, as more fully disclosed herein.

With respect to each VM of one or more VMs (e.g., 130, 132, and/or 134,. . . ) associated with the project, for a given VM with a given flavor,the assignment management component 136, employing the estimatorcomponent 140 and the function component 306, can apply a function,which can be denoted by f, to a set of available and/or defined (e.g.,predefined) parameters or characteristics associated with the VM. Theset of available and/or defined parameters or characteristics cancomprise one or more parameters or characteristics. The parameters orcharacteristics can comprise, for example: 1) the parameters associatedwith the flavor of the VM, such as a flavor size of the VM, a number ofvCPUs (e.g., number of cores) associated with the VM, a memory size(e.g., random access memory (RAM) size) associated with the VM, anephemeral disk space associated with the VM, a communications bandwidthfactor (e.g., RXTX factor) associated with the VM, and/or a swap spaceassociated with the VM; 2) an amount of volume storage and/or blockstorage associated with (e.g., attached to) the VM; and/or 3) one ormore other parameters (if available), such as the hardwarecharacteristics of a server that runs the VM (e.g., the speed and/ortype of the physical NIC card). In some implementations, the parametersor characteristics also can comprise the type and/or characteristics ofhypervisors and the application(s) associated with the VM, wherein theassignment management component 136 (and estimator component 140) candirectly consider such type and/or characteristics of hypervisors andthe application(s) as parameters of the function f of the functioncomponent 306. In other implementations, the assignment managementcomponent 136 (and estimator component 140) can determine (e.g.,calculate or compute) this function on a per hypervisor and/or perapplication basis (e.g., determine respective functions for respectivehypervisors and/or respective applications).

For instance, the assignment management component 136 (or anothercomponent of or associated with the system 100) can denote theparameters or characteristics of function f by a vector X of size (n×1),wherein, for example:

-   -   x₁=the number of vCPUs, x₂=VM's memory size,    -   x₃=VM's ephemeral disk space, x₄=VM's RXTX factor,    -   x₅=the amount of volume storage, and/or    -   x₆=the amount of block storage, etc. (e.g., up through x_(n)),        and wherein n can be virtually any desired number.

The assignment management component 136, employing the estimatorcomponent 140, can apply the function f of the function component 306 tothe set of available and/or defined parameters or characteristicsassociated with the VM (e.g., VM 130), and can classify an estimate ofthe flow size of the VM into one of the L classes/sub-groups (e.g.,large, medium, small, and tiny, where L=4), wherein the estimatorcomponent 140 can estimate an amount (e.g., how heavy) the flow size ofthe VM (e.g., the inbound and outbound traffic of the VM) can be, basedat least in part on the function f and the set of available and/ordefined parameters or characteristics. The assignment managementcomponent 136 (and estimator component 140), by applying (and based atleast in part on the application of) the function f to such parametersor characteristics, can determine or generate an output of the functionf that can be an estimate of a potential flow size of the VM and candetermine the name or index of the sub-group (from the set S={1, . . . ,L}) to which the VM can belongs. The function f can belong to any, or atleast virtually any, set of continuous, discrete, or heuristicfunctions, or their combinations.

For example, the function f can be defined as Equation (1) as follows:

$\begin{matrix}{f = \left\{ \begin{matrix}{{1\mspace{14mu} {if}\mspace{14mu} 0} < {g(X)} \leq {thr}_{1}} \\{{2\mspace{14mu} {if}\mspace{14mu} {thr}_{1}} < {g(X)} \leq {thr}_{2}} \\\vdots \\{{L - {1\mspace{14mu} {if}\mspace{14mu} {thr}_{L - 1}}} < {g(X)} \leq {thr}_{L}} \\{{L\mspace{14mu} {if}\mspace{14mu} {g(X)}} > {thr}_{L}}\end{matrix} \right.} & (1)\end{matrix}$

wherein the function g(X) (e.g., of the function component 306) can beused (e.g., applied) by the estimator component 140 to determine (e.g.,compute) an estimate of the flow-size of a VM as a function of the setof parameters, as denoted by vector X, and wherein the variable thr(thr₁, thr₂, up through thr_(L)) can be thresholds (e.g., flow-sizethresholds) used by the assignment management component 136 toappropriately classify the flow-size estimate of the VM (and thus,classify the VM) into the corresponding class or sub-group of the Lclasses or sub-groups to which the flow size and associated VM belong,based at least in part on the thresholds.

In some implementations, the assignment management component 136 cancomprise a threshold component 308 that can determine, facilitatedetermining, and/or comprise information relating to thresholds that canbe employed to facilitate classifying flow-size estimates and associatedVMs (e.g., 130, 132, 134, . . . ) to facilitate placing the VMs inappropriate classes or sub-groups of VMs. The thresholds of thethreshold component 308 can be respective flow-size estimate values thatcan define respective ranges of flow sizes associated with VMs that canbe associated with respective classes or sub-groups of flow sizes (e.g.,large, medium, small, and/or tiny, . . . ). With regard to each of theone or more VMs, the assignment management component 136 can compare theestimate of the flow size associated with the VM to the thresholdvalues, and can determine the class or sub-group to which the flow sizeand associated VM belong based at least in part on the results of thecomparison, in accordance with the defined assignment criteria.

For instance, if the estimator component 140 (of the assignmentmanagement component 136) determines that the flow size of a VM (e.g.,VM 130) can have a first flow-size value (e.g., g(X) for the VM can havea first flow-size value), the assignment management component 136 cancompare the first flow-size value to the threshold values (e.g., asprovided by the threshold component 308). If, based at least in part onthe threshold comparison, the assignment management component 136determines that the first flow-size value is located in the rangedefined by thrs₁ and thrs₂, the assignment management component 136 candetermine that the first flow-size value and associated VM are to beclassified as being part of the 2^(nd) class (or sub-group), which canbe the “small” class (or group), wherein L=4, and class 1 is identifiedas the “tiny” class, class 2 is identified as the “small” class, class 3is identified as the “medium” class, and class 4 is identified as the“large” class.

The function g(X) can be determined or generated by the assignmentmanagement component 136 (e.g., by the function component 306) or can bereceived by the assignment management component 136 from anothercomponent of or associated with the system 100. In some implementations,as more fully described herein, the function component 306 can update(e.g., modify, adjust, or refine) the function g(X), in accordance withthe defined assignment criteria, wherein the updated function g(X)(e.g., g (X)) can be used to determine flow sizes of VMs (e.g., 130,132, 134, . . . ) that can have improved accuracy (e.g., can be closerto actual flow sizes of VMs) over the estimated VM flow sizes providedby the previous function g(X).

The function g(X) can model the flow-size of a VM (e.g., VM 130), can bedefined in various different linear or non-linear forms, as desired(e.g., in accordance with the defined assignment criteria), and it canbe determined (e.g., by the function component 306 or another component)on per project or tenant basis or per classes of similar projects ortenants. In some implementations, without loss of generality, g(X) canbe defined as g(X):=A^(T)X, wherein A can be a vector of size (n×1)defined as A:=[α₁, α₂, . . . , α_(n)]^(T), wherein n can be virtuallyany desired positive number. The entries of vector A can model theamount of the contribution of each parameter on the flow-size estimateof the VM. The function component 306 (or another component of orassociated with the system 100) can determine the entries of vector Ausing one or more of different supervised and/or unsupervised machinelearning techniques.

For example, in a supervised learning approach, the function component306 (or other component) can utilize a set of training data tofacilitate learning or determining the entries of vector A, wherein suchtraining data set can be determined or generated (e.g., by the functioncomponent 306 (or other component)) based at least in part onmeasurements of real flow sizes of VMs with different parameters orcharacteristics of the VMs (which can be denoted by vector X), in a labenvironment or in an operating cloud. In some implementations, theassignment management component 136 can comprise a measurement component310 that can measure real flow sizes of VMs (e.g., 130, 132, and/or 134,. . . ) with (e.g., based at least in part on) the respective parametersor characteristics of the respective VMs. In some embodiments, themeasurement component 310 can measure real flow sizes and/or performanceindicators (e.g., KPIs) associated with VMs (or other components in thenetwork) to facilitate generation of a model(s) associated with the VMsthat can be determined (e.g., by a modeler component 312) based at leastin part on the measured real flow sizes and/or performance indicators.

In some embodiments, the assignment management component 136 cancomprise a modeler component 312 that can model (e.g., can generate ordetermine a model that can model) other performance metrics orperformance indicators (e.g., KPIs) associated with VMs (e.g., 130, 132,134, . . . ) based at least in part on (e.g., as a function of)parameters or characteristics associated with VMs. For example, themodeler component 312 can model (e.g., can generate or determine a modelthat can model) the latency or packet-loss between two VMs (e.g., VM₁(e.g., 130) and VM₂ (e.g., 132)) as a function g(X₁, X₂), wherein X₁ andX₂ can represent the respective parameters (e.g., flavor size, number ofvCPUs, and/or memory size, . . . ) of VM₁ and VM₂. In this example case,in addition to or as an alternative to X₁ and X₂ representing therespective parameters (e.g., of the set of available and/or definedparameters) associated with the respective VMs, as disclosed herein, X₁and X₂ can include one or more other parameters, such as the speed ofphysical NIC cards associated with the VMs and/or other network devices(e.g., switches and routers), the type and/or characteristics ofhypervisors, and/or the physical location of servers running the twoVMs. As further example, the modeler component 312 can use otherparameters from other sources, such as the parameters or characteristicsof the underlay network (e.g., the capacity of physical links and/orinterfaces of the underlay network) and/or measured performanceindicators (if such measurements are available) to facilitatedetermining and generating the model, which can model and correspond tosuch parameters or characteristics of the underlay network and/or themeasured performance indicators. The modeler component 312 can determinesuch modeling of performance metrics or performance indicatorsassociated with VMs per project or tenant or per classes of similarprojects or tenants, with the same or similar behavior. The modelsdetermined and generated by the modeler component 312 can be employed bythe assignment management component 136 and/or estimator component 140to estimate and/or predict the flow size and/or other performanceindicators (e.g., KPIs) associated with VMs. As a result, such modelscan be utilized (e.g., by the assignment management component 136) toprovide a more predictive cloud networking environment that canfacilitate enhanced network management and operation in cloud networks(e.g., highly dynamic cloud networks).

As an illustrative non-limiting example, which can be relatively lesscomplex to illustrate certain aspects of the disclosed subject matter,the assignment management component 136 (e.g., the function component306) can determine or generate a function f that can be a one-to-one mapbetween a flavor size of a VM (e.g., VM 130) and the potential flow-sizeestimate of the VM. Equation (2) can represent an example of function fin this case, wherein there can be four classes or sub-groups that canbe denoted by large, medium, small and tiny. In this example case, theassignment management component 136 can classify respective IP addressesof the set (e.g., group) of IP addresses into respective subsets (e.g.,sub-groups) of the four subsets respectively named or indexed as large,medium, small, and tiny (for L=4), and the function f can be defined as:f({Large})→{Large}, f({Medium})→{Medium}, f({Small})→{Small},f({Tiny})→{Tiny}. For example, the assignment management component 136can estimate a VM with a large flavor size to have a large flow size,and can classify the VM to the subset of IP addresses allocated for VMswith a large flow size.

$\begin{matrix}{f = \left\{ \begin{matrix}{Tiny} & {{{if}\mspace{14mu} {{VM}'}s\mspace{14mu} {FlavorSize}} = {Tiny}} \\{Small} & {{{if}\mspace{14mu} {{VM}'}s\mspace{14mu} {FlavorSize}} = {Small}} \\{Medium} & {{{if}\mspace{14mu} {{VM}'}s\mspace{14mu} {FlavorSize}} = {Medium}} \\{Large} & {{{if}\mspace{14mu} {{VM}'}s\mspace{14mu} {FlavorSize}} = {Large}}\end{matrix} \right.} & (2)\end{matrix}$

The assignment management component 136 also can comprise an addressassigner component 314 that can assign network addresses to respectiveVMs (e.g., 130, 132, 134, . . . ) (or other network nodes), inaccordance with the defined assignment criteria. For instance, after theassignment management component 136 has classified the respective VMs torespective sub-groups (e.g., subsets) of IP addresses based at least inpart on the respective flow-size estimates of the respective VMs, withrespect to each VM, the address assigner component 314 can assign (e.g.,automatically or manually assign) an IP address from a list of availableIP addresses of the sub-group of VMs to which the VM belongs, inaccordance with a defined assignment algorithm or procedure, and thedefined assignment criteria. In accordance with various embodiments, theassignment algorithm or procedure employed by the address assignercomponent 314 can be the first available IP address on the list ofavailable IP addresses for the sub-group of VMs to which the VM belongs,the least used IP on the list of available IP addresses for thatsub-group of VMs in each group, or any other desired assignmentalgorithm or procedure.

In some embodiments, the assignment management component 136 also cancomprise a rule management component 316 that can determine a desirableset of IP-table/flow-table/TCAM rules (e.g., a compressed set having areduced number of such rules) that can be employed with regard tonetwork devices (e.g., SDN switches or other SDN devices), based atleast in part on the respective flow-size estimates of respective VMs(e.g., 130, 132, 134, . . . ) and/or via application of networkinference techniques or algorithms, as more fully described herein. Thedesirable set of IP-table/flow-table/TCAM rules can be a compressed orreduced set of IP-table/flow-table/TCAM rules that can provide desirablyinformative (e.g., suitably informative, optimally informative, or mostinformative) flow-aggregated measurements for flow-size estimationassociated with VMs (e.g., 130, 132, 134, . . . ).

For example, with regard to various IP-table/flow-table/TCAM rules thatpotentially can be relevant in providing flow-aggregated measurements,the rule management component 316 can determine or identify certainIP-table/flow-table/TCAM rules from all of the variousIP-table/flow-table/TCAM rules (e.g., can determine a compressed set(e.g., a subset) or reduced number of IP-table/flow-table/TCAM rules)that are usable to provide (e.g., determine) flow-aggregatedmeasurements that facilitate determining estimations of flow sizesassociated with virtual machines that can have a higher accuracy thanother estimations of flow sizes of virtual machines that can be obtainedfrom using the other rules of the various IP-table/flow-table/TCAMrules. The rule management component 316 can provide (e.g., present) thecompressed or reduced set of IP-table/flow-table/TCAM rules to, forexample, the network controller component 138, which can use such ruleswith SDN-enabled network devices (e.g., SDN-enabled switches androuters) associated with the communication network 112.

The following examples can illustrate differences between a regular IPassignment and the enhanced (e.g., intelligent) IP assignment of thedisclosed subject matter as well as advantages of the enhanced IPassignment over the regular IP assignment. Consider a pool of private IPaddresses for a project as 10.0.0.0/24, wherein it can be assumed thatthere are four flavor sizes, such as large, medium, small, and tinyassociated with VMs. Also, consider two cases where in both cases therecan be four VMs, wherein two VMs can have a large flavor size and twoVMs can have a small flavor size, and each VM can be assigned with aunique IP. In these examples, and without loss of generality, there canbe a concentration on the destination IP address when describingflow-aggregation feasibility.

For example, in the case of a regular IP address assignment strategy,without loss of generality, it can be assumed based on commonly usedstrategies, IP addresses 10.0.0.212 and 10.0.0.215 are assigned to VMswith a large flow-size and IP addresses 10.0.0.213 and 10.0.0.214 areassigned to VMs with a small flow-size. Now, the destination IP addresspart of aggregated flow-table entries, destined to small and large VMs,can be the same as 10.0.0.(110101XX), wherein “X” can denote a“don't-care” operator. Hence, incoming packets cannot be forwarded basedon the longest priority match, wherein the longest priority match can bea typical or common classification mechanism employed in SDN-enableddevices, such as, for example, OpenFlow-enabled switches (e.g., switchesenabled to use the OpenFlow protocol). This can be an example of aflow-aggregation feasibility constraint. Therefore, four flow-tableentries typically can be used (e.g., required) for routing. In thiscase, although flow-size measurement can be relatively good (e.g.,perfect or virtually perfect), this type of method is not desirablyscalable in large-scale networks, as the number of flow-table/TCAM ruleson SDN-enabled switches can be undesirably limited.

As further example, in the case of the enhanced IP address assignmentstrategy, without loss of generality, it can be assumed that the rangeof IP addresses 10.0.0.0/24 can be partitioned into the followingsubsets of IP addresses and assigned to different sub-groups of VMs(e.g., sub-group of VMs with a determined or defined tiny flow size,sub-group of VMs with a determined or defined small flow size, sub-groupof VMs with a determined or defined medium flow size, and sub-group ofVMs with a determined or defined large flow size), wherein, in thisexample, the subsets of IP addresses and associated VM sub-groups cancomprise:

-   -   tiny={10.0.0.1, . . . , 10.0.0.127};    -   small={10.0.0.128, . . . , 10.0.0.191};    -   medium={10.0.0.192, . . . , 10.0.0.252}; and    -   large={10.0.0.253, 10.0.0.254}.        For instance, the assignment management component 136 (e.g.,        employing the partition component 302) can partition the set of        IP addresses (e.g., range of available IP addresses) into        respective subsets of IP addresses and can assign the respective        subsets of IP addresses to respective sub-groups of VMs (e.g.,        tiny, small, medium, large), as presented above.

It is to be appreciated and understood that, in accordance with variousembodiments of the disclosed subject matter, the assignment managementcomponent 136 can partition the available IP addresses into respective(e.g., different) subsets of IP addresses and assign the respectivesubsets of IP addresses to respective sub-groups of VMs in a variety ofdifferent ways. For instance, another option for partitioning the set ofavailable IP addresses into respective subsets of IP addresses andassigning the respective (e.g., different) subsets of IP addresses torespective (e.g., different) sub-groups of VMs (e.g., by the assignmentmanagement component 136) can be large={10.0.0.1, 10.0.0.2},medium={10.0.0.3, . . . , 10.0.0.64}, small={10.0.0.65, . . . ,10.0.0.127}, and tiny={10.0.0.128, 10.0.0.254}. It also is to beappreciated and understood that, in accordance with various aspects andembodiments of the disclosed subject matter, the number of sub-groups ofVMs to which respective subsets of IP addresses can be assigned (e.g.,by the assignment management component 136) can be four (as in theexample) sub-groups of VMs, less than four sub-groups of VMs, or morethan four sub-groups of VMs, based at least in part on the applicabledefined assignment criteria.

In accordance with the example, it can be assumed that the assignmentmanagement component 136 (e.g., the partition component 302) assigned IPaddresses 10.0.0.253 and 10.0.0.254 to VMs with an estimated large flowsize, and assigned IP addresses 10.0.0.128 and 10.0.0.129 to VMs with anestimated small flow size. Based at least in part on such assignments ofIP addresses, the assignment management component 136 can determine thatthe aggregated flow-table entries, which can be destined to VMsassociated with a small flow size and VMs associated with a large flowsize, respectively, can be 10.0.0.(1000000X) and 10.0.0.(111111XX),wherein “X” can denote a “don't-care” operator. The network controllercomponent 138 can facilitate configuring network devices (e.g.,SDN-enabled switches and routers) using the aggregated flow-tableentries, and, using such aggregated flow-table entries, incoming datapackets can be forwarded by the network devices (e.g., SDN-enabledswitches and routers) without any flow aggregation feasibilityconstraint.

To illustrate the estimation accuracy and for explanation purposes,assume that flow sizes are normalized between 0-100 units where [0-25]units indicate a tiny flow-size, [26-50] units indicate a smallflow-size, [51-75] units indicate a medium flow-size, and [76-100] unitsindicate a large flow-size. It is to be appreciated and understood thatdefining flow-size ranges is not necessary for implementing the enhancedIP address assignment techniques (e.g., by the assignment managementcomponent 136), as disclosed herein. In this example illustration, flowranges are used merely to illustrate the accuracy that can be achievedby employing the enhanced IP address assignment techniques of thedisclosed subject matter.

It also is to be appreciated and understood that, if these exampleranges are utilized (e.g., required) in practice, the link-bandwidth(e.g., capacity) can be used as the maximum allowable flow-size andthese ranges can be computed. For instance, flow sizes less than 1% oflink capacity can be considered as tiny flows; and this procedure alsocan be extended to other flow-size ranges. It is noted that, to improvethe flow-size estimation accuracy, the range of flow sizes for differentgroups can be modified (e.g., enhanced, improved, or optimized).

With further regard to this example, consider a worst-case scenariowhere flows destined to small flow-size VMs respectively have sizes 26and 50, and flows destined to large flow-size VMs respectively havesizes 76 and 100. Therefore, counters associated with the above twoaggregated flows can provide counts of 76 and 176, respectively.Accordingly, using a basic flow-estimation technique (e.g., calculatingthe average which can indicate the worst case), the flow sizes estimatescan be

$\frac{76}{2} = 38$

for small flows and

$\frac{176}{2} = 88$

for large flows. Hence, as can be observed, there are only 12 units oferror for estimating the flow sizes in the worst-case scenario.

While such error in estimating the flow sizes in the worst-case scenariocan be acceptable, it is noted that the assignment management component136, or another component of or associated with the system 100,employing the disclosed subject matter can improve flow-size estimationaccuracy by, for example, using desirable (e.g., better or improved)estimation techniques (e.g., compressed sensing estimation techniques),enhancing (e.g., improving or optimizing) the range of flow sizes fordifferent sub-groups of VMs, and/or introducing more flow-sizesub-groups than in the above example (e.g., introducing five flow-sizesub-groups (L=5), instead of four flow-size sub-groups (L=4)). That is,the flow-size estimation accuracy can be based at least in part on theestimation technique employed in the estimation, the range of flow sizesutilized for different groups, and/or the number of flow-size groups ofVMs employed. Accordingly, by employing techniques for the enhancedassignment of IP addresses to VMs, the disclosed subject matter canachieve a desirable (e.g., an appropriate, suitable, or acceptable)trade-off between flow-size estimation accuracy and the number ofrequired flow-table entries, which can be of significance under hardconstraint of network measurement resources in large-scale networks(e.g., flow-table/TCAM entries in SDN switches).

Table 1 (below) summarizes the comparison between these two examplecases (e.g., regular IP address assignment strategy as compared to theenhanced IP address assignment strategy of the disclosed subjectmatter). Note that, although, with regard to the regular IP addressassignment, the flow-size measurement is relatively more accurate, it isnot scalable in large-scale networks, and thus, may not be suitable inlarge-scale networks. However, with regard to the enhanced IP addressassignment of the disclosed subject matter, the disclosed subject matter(e.g., employing the assignment management component 136 and enhanced IPaddress assignment techniques) can provide a desirable trade-off betweenthe flow-size estimation accuracy and the number of utilized (e.g.,required) flow-table/TCAM rules, which, even in this basic example, hasbeen decreased by 50%, as compared to the regular IP address assignmentstrategy, and can provide an even better trade-off in other IPassignment situations.

TABLE 1 A comparison between two cases. # of flow-table/TCAM Estimationrules Accuracy Considerations Regular IP 4 Can have 0 units of NotScalable address error strategy Enhanced IP 2 Can have 12 units Scalableand address of error (in the Effective strategy worst-case scenario)

There can be a number of advantages that can be gained from employingthe enhanced (e.g., intelligent) IP assignment techniques, based atleast in part on an estimate of flow sizes using the defined parametersof VMs (e.g., 130, 132, 134, . . . ) in a cloud environment, inaccordance with the various aspects and embodiments of the disclosedsubject matter. For example, the enhanced IP assignment techniques ofthe disclosed subject matter can provide a desirably compressed (e.g.,reduced) set of IP-table/flow-table/TCAM rules that can providedesirably informative (e.g., suitably informative, optimallyinformative, or the most informative) flow-aggregated measurements forflow-size estimation for VMs with desirably (e.g., suitably, optimally)high accuracy via the application of network inference techniques, asdisclosed herein. For instance, the assignment management component 136can comprise a rule management component 316 that can determine orfacilitate determining the desirably compressed or reduced set ofIP-table/flow-table/TCAM rules that can provide the desirablyinformative flow-aggregated measurements for flow-size estimation forVMs with the desirably (e.g., suitably, optimally) high accuracy. Thiscan be of significant importance in large-scale networks and under hardresource constraints of limited flow-table/TCAM sizes in SDNswitches/routers. Note that, without loss of generality, theflow-table/TCAM rules, which can be obtained using the enhanced IPassignment techniques, can be provided (e.g., by the assignmentmanagement component 136 or network controller component 138) in a waythat can be compatible with an underlying routing mechanism associatedwith the communication network 112.

Also, the enhanced IP assignment techniques of the disclosed subjectmatter can match (e.g., be compatible) or be employed with other IPassigning strategies, such as, for example, a least recently used IP inDHCP. In this example case, the least recently used IP from each groupcan be assigned to the VM that belongs to that group.

Still another advantage of the disclosed subject matter can be that theassignment management component 136 (or another component of thedisclosed subject matter) can achieve desirable load balancing over IPaddresses assigned to each sub-group by the assignment managementcomponent 136, which can reduce the load on each flow-table/TCAM rule(e.g., particularly for heavy loaded VMs with, for example, large flavorsizes). The achieving of desirable load-balancing performance can beused (e.g., by the assignment management component 136 or othercomponent) as criteria for determining (e.g., computing) the number ofIP addresses for each sub-group of VMs (e.g., respective sub-groups ofVMs having respective ranges of estimated flow sizes).

Yet another advantage of the disclosed subject matter can be thatemploying the assignment management component 136 and the enhanced IPaddress assignment technique to desirably assign IP addresses to VMs canmake network management easier, and it also can reduce or mitigate theflow-aggregation feasibility constraint among different subnets fromdifferent sub-groups of private IP addresses.

As still another advantage of the disclosed subject matter, respectiveestimates of flow sizes of respective VMs can be known or determined(e.g., by another component (e.g., evaluator component, securitycomponent, . . . ) based at least in part on the respective assignmentsof IP addresses to the respective VMs by the assignment managementcomponent 136, wherein the respective IP addresses are associated withrespective classes or sub-groups of VMs, wherein the respective classesor sub-groups are associated with respective flow-size ranges andrespective names or indexes. This information regarding the respectiveestimates of flow sizes of respective VMs and the respective classes ornames associated with the respective IP addresses, can result in networkoperation being desirably easier, faster, and/or more efficient, ascompared to traditional network operations. For example, employing thetechniques of the disclosed subject matter, the respective IP class orsub-group names associated with respective IP addresses can be used(e.g., by the evaluator component or security component, . . . ) foranticipating, predicting, estimating, or determining flow sizes that canbe used for traffic engineering, load balancing, heavy hitter (e.g.,heavy flows), and/or denial of service detection, as more fullydescribed herein.

Another advantage of the disclosed subject matter can be that theenhanced IP address assignment techniques can be readily employed andcan be implemented in a variety of desirable and different ways, withoutrestricting any of traditional or potential applications in cloudcomputing environments. For example, the enhanced IP address assignmenttechniques can select or assign a least used IP address from a sub-groupof IP addresses for or to a VM, wherein the employment of a least-usedIP-address assignment strategy can be compatible with a DHCP strategyfor assigning IP addresses.

Furthermore, in some implementations, without loss of generality, thedisclosed subject matter (e.g., the techniques employed by theassignment management component 136 and/or other components of orassociated with the system 100) can be extended to other fields in flowtables, such as, for example, MAC addresses in flow tables employed withSDN-enabled network devices, which can be yet another advantage of thedisclosed subject matter.

In accordance with various aspects and embodiments of the disclosedsubject matter, the parameter-based estimation of flow sizes of VMsdetermined and employed by the assignment management component 136 andestimator component 140 can be utilized by the assignment managementcomponent 136 or other components (e.g., evaluator component, securitycomponent, . . . ) to make a variety of desirable determinations and/orperform a variety of different tasks or functions that can enhancenetwork operations and data communications in the communication network112, as more fully described herein.

As disclosed, the estimator component 140 can apply the function g(X) todetermine (e.g., compute) an estimate of the flow-size of a VM (e.g.,the volume of the VM's traffic represented in bytes or packets) as afunction of the flavor parameters of the VM and/or other parameters orcharacteristics of or associated with the VM (e.g., VM 130). Theestimator component 140 can model and estimate the volume of traffic ofa server or host based at least in part on (e.g., as a function of) therespective flow-size estimates of respective VMs associated with theserver or host. Having such an estimate for all active VMs associatedwith (e.g., inside) a server/host at each time interval, the estimatorcomponent 140 can determine (e.g., calculate) an estimate of the volumeof the traffic of the server over time as a combination (e.g., a linearcombination) of the flow-size estimates of the VMs running by theserver. Such an estimate can be determined and provided by the estimatorcomponent 140 based at least in part on a set of defined parameters orcharacteristics associated with VMs and without having to perform anydirect network measurement of the flow sizes associated with the VMs. Itcan be desirable (e.g., useful, or important) to have desirably accurateflow-size estimates associated with VMs, without having to performdirect network measurement of the flow sizes associated with the VMs, asthe direct measurement of flow sizes of VMs can be challenging andexpensive in large-scale cloud networks and under hard resourceconstraint of measurement resources.

Further, the estimation of traffic volume(s) of a VM(s) that can bedetermined based at least in part on the defined parameters orcharacteristics of a VM(s) can be desirably (e.g., advantageously) usedin a number of different applications. Referring to FIG. 4 (along withFIGS. 1 and 3), FIG. 4 depicts a block diagram of an example system 400that can facilitate determination of estimations of flow sizesassociated with network nodes and use (e.g., application) of theflow-size estimations to achieve various desired objectives inconnection with networks, in accordance with various aspects andembodiments of the disclosed subject matter. In some embodiments, thesystem 400 can be part of or associated with the network component 110.

The system 400 can comprise the assignment management component 136,which can include the estimator component 140 and function component 306(and other components), and the network controller component 138. Thesystem 400 also can comprise a VM generator component 402, an evaluatorcomponent 404, a security component 406, a processor component 408, anda data store 410.

In some embodiments, the VM generator component 402 (e.g., VM generatorand launcher component) can utilize the estimate of a flow sizeassociated with a VM (e.g., VM 130), which can be determined by theestimator component 140 using function g(X), to determine a desirable(e.g., suitable, enhanced, best, or optimal) placement of the VM with aserver or host of a number of servers or hosts. For instance, based atleast in part on the estimate of the flow size of the VM, the VMgenerator component 402 can determine which server(s) or host(s) havesufficient resources to support the application(s) with which the VM isto be employed, and from such server(s) or host(s), determine which isthe most desirable server or host to use for launching the VM.

In other embodiments, an evaluator component 404 (and/or the estimatorcomponent 140) can use and evaluate parameters of VMs and estimates ofthe flow sizes of VMs (e.g., determined based at least in part onrespective parameters or characteristics associated with respective VMs)to determine and generate performance metrics (e.g., KPIs, such aslatency and/or data packet loss), wherein the performance metrics,parameters of VMs, and/or estimates of flow sizes of VMs can be utilizedto make determinations relating to traffic engineering andload-balancing for desirable (e.g., efficient, effective, enhanced,suitable, and/or optimal) network traffic management. For example, theevaluator component 404 (and/or the estimator component 140) can utilizerespective flow-size estimates of respective VMs (e.g., 130, 132, 134, .. . ) and/or respective parameters of respective VMs to evaluate (e.g.,pre-evaluate) the performance of traffic engineering and load-balancingassociated with traffic being or to be communicated in the communicationnetwork 112.

As another example, the evaluator component 404 (and/or the estimatorcomponent 140) can utilize the respective flow-size estimates of therespective VMs (e.g., 130, 132, 134, . . . ) and/or respectiveparameters of the respective VMs to generate performance metrics, andcan use such performance metrics to evaluate (e.g., pre-evaluate) orpredict one or more of the performance indicators (e.g., KPIs) inadvance, even prior to launching VMs (e.g., by the VM generatorcomponent 402). For instance, the evaluator component 404 (and/or theestimator component 140) can model, estimate, and/or predict performancemetrics and performance indicators (e.g., KPIs) associated with VMs(e.g., 130, 132, 134, . . . ) in cloud networks based at least in parton (e.g., as a function of) the respective parameters or characteristicsassociated with the VMs. The evaluator component 404 (or anothercomponent(s) (e.g., the VM generator component 402 or the estimatorcomponent 140) associated with the system 400), can utilize suchevaluated (e.g., pre-evaluated) performance metrics to facilitateenhanced placement of a VM with a desirable server or host (e.g., by theVM generator component 402), load balancing and traffic engineering forcommunication of traffic in the communication network 112, resourceallocation and orchestration in cloud network environments, and/or makethe applications more predictive and robust against future changes indynamic operational networks.

In certain embodiments, the parameter (or characteristic)-basedflow-size estimates, performance metrics, and/or performance indicatorsof VMs (e.g., determined by the estimator component 140) can be used tofacilitate detecting security attacks or network anomalies associatedwith the communication network 112. For example, the security component406 can evaluate the parameter (or characteristic)-based flow-sizeestimates of VMs (e.g., 130, 132, 134, . . . ) and can compare them toexpected flow-size estimates of the VMs. The expected flow-sizeestimates of the VMs can be determined based at least in part on realflow-size measurements of the VMs or class-estimated flow-size estimatesof the VMs that can be determined based at least in part on therespective classes to which the respective VMs belong.

With regard to a VM (e.g., VM 130), if the security component 406determines that the comparison results of such comparison indicate thatthere is a significant (e.g., large) deviation between the estimatedflow size associated with the VM (as determined using the function g(X))and the expected flow-size estimate associated with the VM (e.g., VM130) that satisfies (e.g., exceeds) a defined threshold amount ofdeviation, the security component 406 can determine that a securityattack associated with the VM or a network anomaly associated with theVM or communication network 112 has occurred, can interpret suchdeviation as the presence of the security attack or the network anomaly,or can determine that such deviation can be an indication that thesecurity attack or the network anomaly may have occurred, in accordancewith defined security criteria. The security attacked can be determinedto be, for example, a denial of service (DoS) attack or distributed DoS(DDoS) attack associated with the VM (e.g., VM 130). The network anomalycan be determined to be, for example, a failure(s) in networkinfrastructure of the communication network 112. The security component406 also can distinguish between a security attack associated with theVM (e.g., VM 130) or a network anomaly associated with the VM orcommunication network 112, based at least in part on the amount ofdeviation and/or other information (e.g., other information that canprovide an indication as to whether there has been a security attack ora network anomaly) obtained from another data source associated with thesecurity component 406, in accordance with the defined network securitycriteria.

In some embodiments, the function component 306 can modify (e.g.,adaptively modify) a function, such as function g(X) or function f overtime, in an online and/or adaptive manner, in accordance with thedefined assignment criteria. This can be performed in productionenvironments (e.g., in real time or substantially real time) or atesting environment, as desired.

For example, the measurement component (e.g., measurement component 310)can measure real (e.g., actual) flow sizes associated with VMs (e.g.,over a desired period(s) of time). The function component 306 (and/orthe analyzer component 304) can analyze and/or compare the estimatedflow sizes associated with VMs (e.g., 130, 132, 134, . . . ) and thereal (e.g., measured) flow sizes associated the VMs that can relate to adefined period of time. The function component 306 can determine theamount of error between the estimated flow sizes associated with VMs andthe real flow sizes associated the VMs associated with the definedperiod of time, based at least in part on the results of analyzingand/or comparing the estimated flow sizes and the real flow sizesassociated the VMs with respect to the defined period of time. Thefunction component 306 can determine (e.g., automatically, dynamically,or adaptively determine) a modification that can be made to the function(e.g., g(X) or f), based at least in part on the results of suchanalyzing and/or comparing, to generate a modified function that canreduce or minimize the amount of error between the estimated flow sizesand the real flow sizes associated the VMs (e.g., 130, 132, 134, . . .). In some implementations, the function component 306 can facilitatedetermining and generating a modified function (e.g., a modified oradapted g (X)) by applying, for instance, a least mean square (LMS)algorithm or another desired algorithm that can reduce or minimize sucherror, and/or by measurement (e.g., by the measurement component 310) ofa set of flow sizes of VMs at particular time intervals (based at leastin part on the application) using a set of limited or reducedTCAM/flow-entries.

In certain embodiments, the assignment management component 136,employing the estimator component 140 and the function component 306,can enhance (e.g., improve) accuracy of estimation of flow sizesassociated with VMs (e.g., 130, 132, 134, . . . ) based at least in parton (e.g., by applying) network inference techniques and related networkinference problems. For example, the assignment management component136, employing the estimator component 140 and the function component306, can convert un-constrained network optimization and networkinference problems (e.g., in cloud networks), into constrainedoptimization problems by incorporating supplementary information thatcan be determined (e.g., computed) using parameter-based flow-sizeestimates associated with VMs and/or parameter-based performance metricestimates associated with VMs.

In some implementations, the assignment management component 136 canincorporate flow-size estimates associated with VMs (e.g., 130, 132,134, . . . ), which have been determined using the function g(X), intonetwork inference problems to facilitate improving the flow-sizeestimation accuracy associated with VMs. For instance, consider atraffic matrix completion problem where matrix Z can represent the flowsizes of VMs (e.g., all VMs) to each other and a subset of the entriesof the matrix Z can be directly measured; this subset of entries can bedenoted by matrix B, where not-measured entries or missed entries can beset to zero. Given matrix B, the goal in matrix completion techniquescan be to estimate the not-measured entries or missed entries of thematrix Z.

One approach that the assignment management component 136 can employ toestimate un-observed entries (e.g., not-measured or missed entries) ofthe matrix Z can be to decompose the matrix Z and re-write or modify thematrix Z to be Z=LR^(T) and solve the following optimization problem ofEquation (3) below, wherein A can be a binary matrix wherein its onesshow measured entries of Z and its zeros show not-measured entries of Z.In this Equation (3), ∥.∥_(F) can be the Frobenius norm, T can be thetranspose operator, and λ can be a non-negative constant value. It isnoted, without loss of generality, that it can be assumed that Z is an(n×n) matrix, wherein n can be virtually any desired positive number.

{circumflex over (Z)}=LR ^(T)=minimize_(L,R ∥) A(LR ^(T))=B∥ _(F)²+λ(∥L∥ _(F) ² +∥R∥ _(F) ²)   (3)

The assignment management component 136 can incorporate the estimates offlow sizes of VMs (e.g., determined using g(X) and based at least inpart on respective defined parameters or characteristics associated withthe respective VMs (e.g., 130, 132, 134, . . . )) into the trafficmatrix completion problem in Equation (3) as constraints. Accordingly,based at least in part on such incorporation, Equation (3) can bemodified to be Equation (4), wherein the flow-size estimates can beconsidered as constraints to the optimization problem of Equation (3).Consequently, employing Equation (4), the assignment managementcomponent 136 can improve the estimation accuracy of flow sizesassociated with VMs due in part to the flow-size estimates being forcedto be in constraint bounds, e.g., as specified in Equation (4), whichcan facilitate avoiding generating large and irrelevant errors relatingto flow sizes associated with VMs.

For example, in Equation (4), g_(i)(X_(i)) can be the flow-size estimateof the i^(th) VM based at least in part on the parameters of such VM,which can be denoted by vector X_(i), wherein i can be virtually anydesired positive number. Also, α_(i) ² and α_(i) ² can be coefficientsthat can determine constraints bounds for the i^(th) VM, and thosecoefficients (e.g., α_(i) ¹ and α_(i) ²) can be desirably (e.g.,appropriately, suitably) set to coefficient values (e.g., α_(i) ¹=0.75and α_(i) ²=1.25) or such coefficients can be estimated (e.g., by theassignment management component 136 or another component), for example,in a supervised learning approach and using a training data set (e.g.,as quartile statistics). In Equation (4), L_(i) and R_(j) ^(T) candenote the i^(th) row of matrix L and j^(th) column of matrix R^(T).Also note that g(X_(i)) for i^(th) VM to itself can be zero. Equation(4) can be as follows:

$\begin{matrix}{{\hat{Z} = {{LR}^{T} = {{{minimize}_{L,R}\; {{{A\left( {LR}^{T} \right)} - B}}_{F}^{2}} + {\lambda \left( {{L}_{F}^{2} + {R}_{F}^{2}} \right)}}}}{{subject}\mspace{20mu} {to}\text{:}}\left\{ \begin{matrix}{{{{\alpha_{1}^{1}{g_{1}\left( X_{1} \right)}} \leq {L_{1}R_{j}^{T}} \leq {\alpha_{1}^{2}{g_{1}\left( X_{1} \right)}\mspace{14mu} {for}\mspace{14mu} j}} = 2},\ldots \mspace{11mu},n} \\{{{{\alpha_{2}^{1}{g_{2}\left( X_{2} \right)}} \leq {L_{2}R_{j}^{T}} \leq {\alpha_{2}^{2}{g_{2}\left( X_{2} \right)}\mspace{14mu} {for}\mspace{14mu} j}} = 1},3,\ldots \mspace{11mu},n} \\\vdots \\{{{{\alpha_{n}^{1}{g_{n}\left( X_{n} \right)}} \leq {L_{n}R_{j}^{T}} \leq {\alpha_{n}^{2}{g_{n}\left( X_{n} \right)}\mspace{14mu} {for}\mspace{14mu} j}} = 1},\ldots \mspace{11mu},{n - 1}}\end{matrix} \right.} & (4)\end{matrix}$

These constraints of Equation (4) can act as supplementary informationfor the matrix completion techniques (e.g., relating to the networkinference techniques), and such constraints can significantly improvethe estimation accuracy of flow-size estimations of VMs (e.g., 130, 132,134, . . . ) of the matrix completion techniques, in accordance with thedisclosed subject matter. It is noted that, in some implementations,such constraints of Equation (4) can be incorporated to other (e.g.,different) optimization formulations for matrix completion to facilitateimproving the estimation accuracy of flow-size estimations of VMs. Also,it should be noted that, such constraints in Equation (4) are merely onenon-limiting illustrative way of representing the constraints for theoptimization problem, and, in other embodiments, these constraints canbe provided in different forms to facilitate improving the estimationaccuracy of flow-size estimations of VMs.

Moreover, such constraints in Equation (4) can be adaptively revised(e.g., by the assignment management component 136) when the mostrecently determined (e.g., computed) functions g(X)s are used. Forexample, if the function component 306 determines the function g(X) isto be modified to a modified function (e.g., g′(X)), the assignmentmanagement component 136 (or another component) can adaptively revisethe constraints of Equation (4) to account for any modifications to thefunction g(X), wherein such revisions to the constraints of Equation (4)can significantly improve the estimation accuracy of flow-sizeestimations of VMs.

As disclosed herein, other performance metrics (e.g., latency or packetloss) also can be modeled as a function of parameters associated with aVM(s). For example, the assignment management component 136 (e.g.,employing the modeler component 312) can model the latency or packetloss between two VMs (e.g., VM 130 and VM 132) based at least in part onthe function g(X₁, X₂), wherein X₁ and X₂ can represent the parametersassociated with VM₁ and VM₂, respectively, and wherein such parameterscan comprise any of the various parameters (e.g., flavor size, number ofvCPUs, and/or memory size, . . . ) disclosed herein. Accordingly, theassignment management component 136 can extend the optimizationformulation in Equation (4) to estimate not-measured entries of a matrixof latencies or packet losses. In this example case, the entries ofmatrix Z can represent delays or packet losses from a VM (e.g., VM 130)to another VM (e.g., VM 132), and the incorporated constraints canenhance the estimation accuracy of inferring not-measured entries of thematrix.

The system 400 can comprise the processor component 408 that can work inconjunction with the other components (e.g., assignment managementcomponent 136, network controller component 138, VM generator component402, evaluator component 404, security component 406, data store 418) tofacilitate performing the various functions of the system 400. Theprocessor component 408 can employ one or more processors,microprocessors, or controllers that can process data, such asinformation relating to determining estimated flow sizes associated withVMs (e.g., 130, 132, 134, . . . ), assigning network addresses, trafficmanagement and distribution, load balancing of traffic, parameters orcharacteristics associated with VMs, traffic flows, policies, definedassignment criteria, defined security criteria, algorithms (e.g.,defined assignment algorithm(s)), protocols, interfaces, tools, and/orother information, to facilitate operation of the system 400, as morefully disclosed herein, and control data flow between the system 400 andother components (e.g., communication devices, base stations, cells,devices of the communication network, data sources, applications,compute component, storage component, database component) associatedwith the system 400.

The data store 410 can store data structures (e.g., user data,metadata), code structure(s) (e.g., modules, objects, hashes, classes,procedures) or instructions, information relating to determiningestimated flow sizes associated with VMs (e.g., 130, 132, 134, . . . ),assigning network addresses, traffic management and distribution, loadbalancing of traffic, parameters or characteristics associated with VMs,traffic flows, policies, defined assignment criteria, defined securitycriteria, algorithms (e.g., defined assignment algorithm(s)), protocols,interfaces, tools, and/or other information, to facilitate controllingoperations associated with the system 400. In an aspect, the processorcomponent 408 can be functionally coupled (e.g., through a memory bus)to the data store 410 in order to store and retrieve information desiredto operate and/or confer functionality, at least in part, to theassignment management component 136, network controller component 138,VM generator component 402, evaluator component 404, security component406, and data store 418, etc., and/or substantially any otheroperational aspects of the system 400.

The aforementioned systems and/or devices have been described withrespect to interaction between several components. It should beappreciated that such systems and components can include thosecomponents or sub-components specified therein, some of the specifiedcomponents or sub-components, and/or additional components.Sub-components could also be implemented as components communicativelycoupled to other components rather than included within parentcomponents. Further yet, one or more components and/or sub-componentsmay be combined into a single component providing aggregatefunctionality. The components may also interact with one or more othercomponents not specifically described herein for the sake of brevity,but known by those of skill in the art.

In view of the example systems and/or devices described herein, examplemethods that can be implemented in accordance with the disclosed subjectmatter can be further appreciated with reference to flowcharts in FIGS.5-6. For purposes of simplicity of explanation, example methodsdisclosed herein are presented and described as a series of acts;however, it is to be understood and appreciated that the disclosedsubject matter is not limited by the order of acts, as some acts mayoccur in different orders and/or concurrently with other acts from thatshown and described herein. For example, a method disclosed herein couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, interaction diagram(s) mayrepresent methods in accordance with the disclosed subject matter whendisparate entities enact disparate portions of the methods. Furthermore,not all illustrated acts may be required to implement a method inaccordance with the subject specification. It should be furtherappreciated that the methods disclosed throughout the subjectspecification are capable of being stored on an article of manufactureto facilitate transporting and transferring such methods to computersfor execution by a processor or for storage in a memory.

FIG. 5 illustrates a flow chart of an example method 500 that canenhance IP address assignments and flow-size estimations ordeterminations associated with VMs in a network, in accordance withvarious aspects and embodiments of the disclosed subject matter. Themethod 500 can be employed by, for example, a cloud management componentcomprising an assignment management component and an estimatorcomponent.

At 502, a set of IP addresses can be partitioned into a desired numberof subsets of IP addresses comprising respective numbers of IPaddresses. The set of IP addresses can be associated with a project, forexample. The assignment management component can partition the set of IPaddresses into a desired number of subsets of IP addresses comprisingrespective numbers of IP addresses (e.g., respective numbers ofconsecutive IP addresses) based at least in part on the application(s)(e.g., characteristics or requirements of the application(s)) associatedwith the project and the defined assignment criteria (e.g., assignmentcriteria relating to the number of subsets of IP addresses to employ).For instance, the assignment management component can partition the setof IP addresses into four subsets of IP addresses, and can associate thefour subsets of IP addresses with respective classifications, such aslarge (e.g., large flavor size or flow size), medium (e.g., mediumflavor size or flow size), small (e.g., small flavor size or flow size),and tiny (e.g., tiny flavor size or flow size). The respective numbersof IP addresses of the subsets of IP addresses can be different fromeach other, or a number of IP addresses of one subset of IP addressescan be the same as another subset of IP addresses.

At 504, for each VM of one or more VMs, an estimate of the flow size ofthe VM can be determined based at least in part on one or morecharacteristics (e.g., parameters) associated with the VM. For each VM,the estimator component can employ (e.g., apply) a function f todetermine (e.g., calculate) an estimate of the flow size of the VM basedat least in part on the one or more characteristics associated with theVM. The one or more characteristics associated with the VM can comprise,for example, flavor size of the VM, number of vCPUs associated with theVM, memory size of the VM, ephemeral disk space of VM, RXTX factor ofthe VM, swap space of the VM, the amount of volume storage and/or blockstorage associated with (e.g., attached to) the VM, hardwarecharacteristics of the server that runs the VM (e.g., the speed and/ortype of the physical NIC card), and/or other characteristics. The typeand/or characteristics of hypervisors and the application(s) associatedwith the VM also can be directly considered as characteristics of thefunction f, or the function can be determined (e.g., computed) perhypervisor and/or application (e.g., by the assignment managementcomponent or another component).

At 506, for each VM, the VM can be classified into a classificationassociated with one of the subsets of IP addresses based at least inpart on the estimate of the flow size of the VM. With respect to eachVM, the assignment management component (e.g., employing the estimatorcomponent) can apply the function f to classify the VM into one of theclassifications associated with one of the subsets of IP addresses basedat least in part on the estimate of the flow size of the VM. That is,applying the function f to the characteristics associated with the VMcan produce (e.g., determine) an estimate of the flow size of the VM,and determine the name or index (e.g., classification) of the subset(e.g., group) to which the VM belongs based at least in part on theestimate of the flow size and a set of threshold values relating to flowsizes and the classifications, wherein the set of threshold values canbe part of the function f The names or indexes can comprise, forexample, large, medium, small, and/or tiny. The assignment managementcomponent can classify the VM to one of those names or indexes based atleast in part on the results of comparing of evaluating the estimate ofthe flow size of the VM with respect to the threshold values of thefunction f. The assignment management component can assign the VM to thesubset of IP addresses associated with that name or index to which theVM is classified.

At 508, an IP address from the subset of IP addresses associated withthe classification of the VM can be assigned (e.g., automatically ormanually assigned) to the VM. The assignment management component canassign (e.g., automatically or manually assign) an IP address from thesubset of IP addresses associated with the classification of the VM tothe VM, in accordance with the defined assignment criteria and/or anassignment procedure. The assignment procedure can be, for example, thefirst available IP address of that subset of IP addresses, the leastused IP address of that subset of IP addresses, or another desiredassignment procedure, which can be specified by the defined assignmentcriteria.

The method 500 can continue to be performed (e.g., by the assignmentmanagement component), for example, until all the VMs have beenclassified and had IP addresses assigned to them.

FIG. 6 presents a flow chart of an example method 600 that can enhanceIP address assignments and flow-size estimations or determinationsassociated with VMs in a network to facilitate VM placement, trafficmanagement and load balancing, resource allocation, and/or orchestrationin cloud networks, in accordance with various aspects and embodiments ofthe disclosed subject matter. The method 600 can be employed by, forexample, a cloud management component comprising an assignmentmanagement component, an estimator component, VM generator component,evaluator component, and/or security component.

At 602, for each of one or more VMs, an estimate of the flow size of aVM can be determined based at least in part on one or morecharacteristics (e.g., parameters) associated with the VM. For each VM,the estimator component can employ (e.g., apply) a function g(X) todetermine (e.g., calculate) an estimate of the flow size of the VM basedat least in part on the one or more characteristics (e.g., flavor sizeof the VM, number of vCPUs associated with the VM, memory size of theVM,) associated with the VM, as more fully described herein.

At 604, one or more tasks can be performed and/or one or moredeterminations can be made, based at least in part on the estimate(s) ofthe flow size of the one or more VMs, to facilitate enhancing (e.g.,improving) network, performance, management, and communications. Theestimation of a flow size of a VM can be used in a variety of differentapplications. For example, the VM generator component can determine adesirable (e g , enhanced, suitable, acceptable, or optimal) placementof the VM with respect to a server or host (e.g., determine the bestserver or host for launching the VM, wherein such server or host hassufficient resources to support the application(s) associated with theVM). As another example, the evaluator component can analyze theestimate(s) of flow size of one or more VMs, and/or othernetwork-related information, and, based at least in part on the resultsof the analysis, the evaluator component can make one or moredeterminations regarding traffic engineering or load balancing foreffective network traffic management to achieve desirable (e.g., fast,efficient) communication of traffic in the communication network.

As still another example, the evaluator component can determine andevaluate (e.g., pre-evaluate) the performance of traffic engineering andload balancing for a communication network, and/or predict one or moreperformance indicators (e.g., KPIs) associated with a VM(s) in advance,based at least in part on the results of analysis of the respectiveestimates of flow sizes of respective VMs and/or other network-relatedinformation, even before launching the VMs. The evaluator component alsocan utilize such performance metrics (e.g., pre-evaluated performancemetrics) to make determinations or decisions, and/or perform tasks,regarding VM placement, resource allocation and orchestration in cloudnetworks. This can make these applications more predictive and robustagainst future changes in dynamic operational networks.

As yet another example, the security component can determine or detect asecurity attack or network anomaly based at least in part on the resultsof analyzing the estimate(s) of flow size of one or more VMs. Forinstance, with regard to one or more VMs, if the security componentdetermines that there is a significant (e.g., large) deviation fromflow-size estimates, the security component can determine that suchsignificant deviation represents (e.g., can interpret such significantdeviation as) the presence of an attack (e.g., DoS attack or DDoSattack) or a network anomaly (e.g., due to failures in networkinfrastructure).

In order to provide a context for the various aspects of the disclosedsubject matter, FIGS. 7 and 8 as well as the following discussion areintended to provide a brief, general description of a suitableenvironment in which the various aspects of the disclosed subject mattermay be implemented. While the subject matter has been described above inthe general context of computer-executable instructions of a computerprogram that runs on a computer and/or computers, those skilled in theart will recognize that this disclosure also can or may be implementedin combination with other program modules. Generally, program modulesinclude routines, programs, components, data structures, etc. thatperform particular tasks and/or implement particular abstract datatypes. Moreover, those skilled in the art will appreciate that thevarious methods may be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, mini-computing devices, mainframe computers, as well aspersonal computers, hand-held computing devices (e.g., mobile phone,electronic tablets or pads, laptop computers, PDAs,),microprocessor-based or programmable consumer or industrial electronics,and the like. The illustrated aspects may also be practiced indistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network.However, some, if not all aspects of this disclosure can be practiced onstand-alone computers. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

With reference to FIG. 7, a suitable environment 700 for implementingvarious aspects of this disclosure includes a computer 712. The computer712 includes a processing unit 714, a system memory 716, and a systembus 718. It is to be appreciated that the computer 712 can be used inconnection with implementing one or more of the systems, components, ormethods shown and described in connection with FIGS. 1-6, or otherwisedescribed herein. The system bus 718 couples system componentsincluding, but not limited to, the system memory 716 to the processingunit 714. The processing unit 714 can be any of various availableprocessors. Dual microprocessors and other multiprocessor architecturesalso can be employed as the processing unit 714.

The system bus 718 can be any of several types of bus structure(s)including the memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, Industrial StandardArchitecture (ISA), Micro-Channel Architecture (MSA), Extended ISA(EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus(USB), Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), Firewire (IEEE 1394), and SmallComputer Systems Interface (SCSI).

The system memory 716 includes volatile memory 720 and nonvolatilememory 722. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computer712, such as during start-up, is stored in nonvolatile memory 722. Byway of illustration, and not limitation, nonvolatile memory 722 caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable programmable ROM(EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g.,ferroelectric RAM (FeRAM)). Volatile memory 720 includes random accessmemory (RAM), which acts as external cache memory. By way ofillustration and not limitation, RAM is available in many forms such asstatic RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), doubledata rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM(SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM),and Rambus dynamic RAM.

Computer 712 also includes removable/non-removable,volatile/non-volatile computer storage media. FIG. 7 illustrates, forexample, a disk storage 724. Disk storage 724 includes, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memorystick. The disk storage 724 also can include storage media separately orin combination with other storage media including, but not limited to,an optical disk drive such as a compact disk ROM device (CD-ROM), CDrecordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or adigital versatile disk ROM drive (DVD-ROM). To facilitate connection ofthe disk storage devices 724 to the system bus 718, a removable ornon-removable interface is typically used, such as interface 726.

FIG. 7 also depicts software that acts as an intermediary between usersand the basic computer resources described in the suitable operatingenvironment 700. Such software includes, for example, an operatingsystem 728. Operating system 728, which can be stored on disk storage724, acts to control and allocate resources of the computer system 712.System applications 730 take advantage of the management of resources byoperating system 728 through program modules 732 and program data 734stored, e.g., in system memory 716 or on disk storage 724. It is to beappreciated that this disclosure can be implemented with variousoperating systems or combinations of operating systems.

A user enters commands or information into the computer 712 throughinput device(s) 736. Input devices 736 include, but are not limited to,a pointing device such as a mouse, trackball, stylus, touch pad,keyboard, microphone, joystick, game pad, satellite dish, scanner, TVtuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 714through the system bus 718 via interface port(s) 738. Interface port(s)738 include, for example, a serial port, a parallel port, a game port,and a universal serial bus (USB). Output device(s) 740 use some of thesame type of ports as input device(s) 736. Thus, for example, a USB portmay be used to provide input to computer 712, and to output informationfrom computer 712 to an output device 740. Output adapter 742 isprovided to illustrate that there are some output devices 740 likemonitors, speakers, and printers, among other output devices 740, whichrequire special adapters. The output adapters 742 include, by way ofillustration and not limitation, video and sound cards that provide ameans of connection between the output device 740 and the system bus718. It should be noted that other devices and/or systems of devicesprovide both input and output capabilities such as remote computer(s)744.

Computer 712 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)744. The remote computer(s) 744 can be a personal computer, a server, arouter, a network PC, a workstation, a microprocessor based appliance, apeer device or other common network node and the like, and typicallyincludes many or all of the elements described relative to computer 712.For purposes of brevity, only a memory storage device 746 is illustratedwith remote computer(s) 744. Remote computer(s) 744 is logicallyconnected to computer 712 through a network interface 748 and thenphysically connected via communication connection 750. Network interface748 encompasses wire and/or wireless communication networks such aslocal-area networks (LAN), wide-area networks (WAN), cellular networks,etc. LAN technologies include Fiber Distributed Data Interface (FDDI),Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and thelike. WAN technologies include, but are not limited to, point-to-pointlinks, circuit switching networks like Integrated Services DigitalNetworks (ISDN) and variations thereon, packet switching networks, andDigital Subscriber Lines (DSL).

Communication connection(s) 750 refers to the hardware/software employedto connect the network interface 748 to the bus 718. While communicationconnection 750 is shown for illustrative clarity inside computer 712, itcan also be external to computer 712. The hardware/software necessaryfor connection to the network interface 748 includes, for exemplarypurposes only, internal and external technologies such as, modemsincluding regular telephone grade modems, cable modems and DSL modems,ISDN adapters, and Ethernet cards.

FIG. 8 is a schematic block diagram of a sample-computing environment800 (e.g., computing system) with which the subject matter of thisdisclosure can interact. The system 800 includes one or more client(s)810. The client(s) 810 can be hardware and/or software (e.g., threads,processes, computing devices). The system 800 also includes one or moreserver(s) 830. Thus, system 800 can correspond to a two-tier clientserver model or a multi-tier model (e.g., client, middle tier server,data server), amongst other models. The server(s) 830 can also behardware and/or software (e.g., threads, processes, computing devices).The servers 830 can house threads to perform transformations byemploying this disclosure, for example. One possible communicationbetween a client 810 and a server 830 may be in the form of a datapacket transmitted between two or more computer processes.

The system 800 includes a communication framework 850 that can beemployed to facilitate communications between the client(s) 810 and theserver(s) 830. The client(s) 810 are operatively connected to one ormore client data store(s) 820 that can be employed to store informationlocal to the client(s) 810. Similarly, the server(s) 830 are operativelyconnected to one or more server data store(s) 840 that can be employedto store information local to the servers 830.

It is to be noted that aspects, features, and/or advantages of thedisclosed subject matter can be exploited in substantially any wirelesstelecommunication or radio technology, e.g., Wi-Fi; Gi-Fi; Hi-Fi;Bluetooth; worldwide interoperability for microwave access (WiMAX);enhanced general packet radio service (enhanced GPRS); third generationpartnership project (3GPP) long term evolution (LTE); third generationpartnership project 2 (3GPP2) ultra mobile broadband (UMB); 3GPPuniversal mobile telecommunication system (UMTS); high speed packetaccess (HSPA); high speed downlink packet access (HSDPA); high speeduplink packet access (HSUPA); GSM (global system for mobilecommunications) EDGE (enhanced data rates for GSM evolution) radioaccess network (GERAN); UMTS terrestrial radio access network (UTRAN);LTE advanced (LTE-A); etc. Additionally, some or all of the aspectsdescribed herein can be exploited in legacy telecommunicationtechnologies, e.g., GSM. In addition, mobile as well non-mobile networks(e.g., the internet, data service network such as internet protocoltelevision (IPTV), etc.) can exploit aspects or features describedherein.

Various aspects or features described herein can be implemented as amethod, apparatus, system, or article of manufacture using standardprogramming or engineering techniques. In addition, various aspects orfeatures disclosed in the subject specification can also be realizedthrough program modules that implement at least one or more of themethods disclosed herein, the program modules being stored in a memoryand executed by at least a processor. Other combinations of hardware andsoftware or hardware and firmware can enable or implement aspectsdescribed herein, including disclosed method(s). The term “article ofmanufacture” as used herein is intended to encompass a computer programaccessible from any computer-readable device, carrier, or storage media.For example, computer-readable storage media can include but are notlimited to magnetic storage devices (e.g., hard disk, floppy disk,magnetic strips, etc.), optical discs (e.g., compact disc (CD), digitalversatile disc (DVD), blu-ray disc (BD), etc.), smart cards, and memorydevices comprising volatile memory and/or non-volatile memory (e.g.,flash memory devices, such as, for example, card, stick, key drive,etc.), or the like. In accordance with various implementations,computer-readable storage media can be non-transitory computer-readablestorage media and/or a computer-readable storage device can comprisecomputer-readable storage media.

As it is employed in the subject specification, the term “processor” canrefer to substantially any computing processing unit or devicecomprising, but not limited to, single-core processors;single-processors with software multithread execution capability;multi-core processors; multi-core processors with software multithreadexecution capability; multi-core processors with hardware multithreadtechnology; parallel platforms; and parallel platforms with distributedshared memory. A processor can be or can comprise, for example, multipleprocessors that can include distributed processors or parallelprocessors in a single machine or multiple machines. Additionally, aprocessor can comprise or refer to an integrated circuit, an applicationspecific integrated circuit (ASIC), a digital signal processor (DSP), aprogrammable gate array (PGA), a field PGA (FPGA), a programmable logiccontroller (PLC), a complex programmable logic device (CPLD), a statemachine, a discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. Further, processors can exploit nano-scalearchitectures such as, but not limited to, molecular and quantum-dotbased transistors, switches and gates, in order to optimize space usageor enhance performance of user equipment. A processor may also beimplemented as a combination of computing processing units.

A processor can facilitate performing various types of operations, forexample, by executing computer-executable instructions. When a processorexecutes instructions to perform operations, this can include theprocessor performing (e.g., directly performing) the operations and/orthe processor indirectly performing operations, for example, byfacilitating (e.g., facilitating operation of), directing, controlling,or cooperating with one or more other devices or components to performthe operations. In some implementations, a memory can storecomputer-executable instructions, and a processor can be communicativelycoupled to the memory, wherein the processor can access or retrievecomputer-executable instructions from the memory and can facilitateexecution of the computer-executable instructions to perform operations.

In certain implementations, a processor can be or can comprise one ormore processors that can be utilized in supporting a virtualizedcomputing environment or virtualized processing environment. Thevirtualized computing environment may support one or more virtualmachines representing computers, servers, or other computing devices. Insuch virtualized virtual machines, components such as processors andstorage devices may be virtualized or logically represented.

In the subject specification, terms such as “store,” “storage,” “datastore,” data storage,” “database,” and substantially any otherinformation storage component relevant to operation and functionality ofa component are utilized to refer to “memory components,” entitiesembodied in a “memory,” or components comprising a memory. It is to beappreciated that memory and/or memory components described herein can beeither volatile memory or nonvolatile memory, or can include bothvolatile and nonvolatile memory.

By way of illustration, and not limitation, nonvolatile memory caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable ROM (EEPROM), or flashmemory. Volatile memory can include random access memory (RAM), whichacts as external cache memory. By way of illustration and notlimitation, RAM is available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM). Additionally, the disclosed memory componentsof systems or methods herein are intended to comprise, without beinglimited to comprising, these and any other suitable types of memory.

As used in this application, the terms “component”, “system”,“platform”, “framework”, “layer”, “interface”, “agent”, and the like,can refer to and/or can include a computer-related entity or an entityrelated to an operational machine with one or more specificfunctionalities. The entities disclosed herein can be either hardware, acombination of hardware and software, software, or software inexecution. For example, a component may be, but is not limited to being,a process running on a processor, a processor, an object, an executable,a thread of execution, a program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components may reside within a processand/or thread of execution and a component may be localized on onecomputer and/or distributed between two or more computers.

In another example, respective components can execute from variouscomputer readable media having various data structures stored thereon.The components may communicate via local and/or remote processes such asin accordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal). As another example, a component can be anapparatus with specific functionality provided by mechanical partsoperated by electric or electronic circuitry, which is operated by asoftware or firmware application executed by a processor. In such acase, the processor can be internal or external to the apparatus and canexecute at least a part of the software or firmware application. As yetanother example, a component can be an apparatus that provides specificfunctionality through electronic components without mechanical parts,wherein the electronic components can include a processor or other meansto execute software or firmware that confers at least in part thefunctionality of the electronic components. In an aspect, a componentcan emulate an electronic component via a virtual machine, e.g., withina cloud computing system.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom context, “X employs A or B” is intended to mean any of the naturalinclusive permutations. That is, if X employs A; X employs B; or Xemploys both A and B, then “X employs A or B” is satisfied under any ofthe foregoing instances. Moreover, articles “a” and “an” as used in thesubject specification and annexed drawings should generally be construedto mean “one or more” unless specified otherwise or clear from contextto be directed to a singular form.

Moreover, terms like “user equipment” (UE), “mobile station,” “mobile,”“wireless device,” “wireless communication device,” “subscriberstation,” “subscriber equipment,” “access terminal,” “terminal,”“handset,” and similar terminology are used herein to refer to awireless device utilized by a subscriber or user of a wirelesscommunication service to receive or convey data, control, voice, video,sound, gaming, or substantially any data-stream or signaling-stream. Theforegoing terms are utilized interchangeably in the subjectspecification and related drawings. Likewise, the terms “access point”(AP), “base station,” “node B,” “evolved node B” (eNode B or eNB), “homenode B” (HNB), “home access point” (HAP), and the like are utilizedinterchangeably in the subject application, and refer to a wirelessnetwork component or appliance that serves and receives data, control,voice, video, sound, gaming, or substantially any data-stream orsignaling-stream from a set of subscriber stations. Data and signalingstreams can be packetized or frame-based flows.

Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,”“owner,” “agent,” and the like are employed interchangeably throughoutthe subject specification, unless context warrants particulardistinction(s) among the terms. It should be appreciated that such termscan refer to human entities or automated components supported throughartificial intelligence (e.g., a capacity to make inference based oncomplex mathematical formalisms), which can provide simulated vision,sound recognition and so forth.

As used herein, the terms “example,” “exemplary,” and/or “demonstrative”are utilized to mean serving as an example, instance, or illustration.For the avoidance of doubt, the subject matter disclosed herein is notlimited by such examples. In addition, any aspect or design describedherein as an “example,” “exemplary,” and/or “demonstrative” is notnecessarily to be construed as preferred or advantageous over otheraspects or designs, nor is it meant to preclude equivalent exemplarystructures and techniques known to those of ordinary skill in the art.Furthermore, to the extent that the terms “includes,” “has,” “contains,”and other similar words are used in either the detailed description orthe claims, such terms are intended to be inclusive, in a manner similarto the term “comprising” as an open transition word, without precludingany additional or other elements.

It is to be appreciated and understood that components (e.g., virtualmachine, network node, cloud management component, assignment managementcomponent, estimator component, network component, compute component,storage component, database component, network controller component,communication network, overlay/underlay network component, processorcomponent, data store, . . . ), as described with regard to a particularsystem or method, can include the same or similar functionality asrespective components (e.g., respectively named components or similarlynamed components) as described with regard to other systems or methodsdisclosed herein.

What has been described above includes examples of systems and methodsthat provide advantages of the disclosed subject matter. It is, ofcourse, not possible to describe every conceivable combination ofcomponents or methods for purposes of describing the disclosed subjectmatter, but one of ordinary skill in the art may recognize that manyfurther combinations and permutations of the disclosed subject matterare possible. Furthermore, to the extent that the terms “includes,”“has,” “possesses,” and the like are used in the detailed description,claims, appendices and drawings such terms are intended to be inclusivein a manner similar to the term “comprising” as “comprising” isinterpreted when employed as a transitional word in a claim.

What is claimed is:
 1. A method, comprising: determining, by a systemcomprising a processor, a flow size associated with a network node basedon a characteristic associated with the network node; and based on theflow size, determining, by the system, a network address that is to beassigned to the network node from a group of network addressesassociated with a classification relating to a range of flow sizes. 2.The method of claim 1, further comprising: in response to thedetermining of the network address to be assigned to the network node,assigning, by the system, the network address of the group of networkaddresses associated with the classification to the network node basedon the flow size, wherein the flow size has been determined to beassociated with the classification of a group of classificationscomprising respective classifications relating to respective ranges offlow sizes, wherein the respective classifications comprise theclassification, and wherein the respective ranges of flow sizes comprisethe range of flow sizes.
 3. The method of claim 1, wherein thedetermining the network address that is to be assigned to the networknode from the group of network addresses comprises determining thenetwork address that is to be assigned to the network node from thegroup of network addresses based on a first available network address ofthe group of network addresses or a least used network address of thegroup of network addresses, and wherein the least used network addressis determined to have been used less than other network addresses of thegroup of network addresses.
 4. The method of claim 1, wherein thenetwork address is an Internet protocol address or a media accesscontrol address.
 5. The method of claim 1, further comprising:estimating, by the system, the flow size associated with the networknode based on the characteristic associated with the network node,wherein the determining the flow size associated with the network nodecomprises determining the flow size associated with the network nodebased on the estimating of the flow size.
 6. The method of claim 5,further comprising: determining, by the system, a model of flow sizesassociated with network nodes in relation to characteristics associatedwith the network nodes based on real flow sizes associated with networknodes, wherein the real flow sizes are measured, and wherein theestimating the flow size associated with the network node based on thecharacteristic associated with the network node comprises estimating theflow size associated with the network node based on the characteristicassociated with the network node and the model.
 7. The method of claim5, wherein the network node is a virtual machine, and wherein thecharacteristic associated with the virtual machine comprises a number ofvirtual central processing units associated with the virtual machine, aflavor size associated with the virtual machine, a memory sizeassociated with the virtual machine, a disk space associated with thevirtual machine, a receive and transmit factor associated with thevirtual machine, a swap space associated with the virtual machine, afirst amount of volume storage associated with the virtual machine, asecond amount of block storage associated with the virtual machine, aserver characteristic of a server associated with the virtual machine, ahypervisor characteristic of a hypervisor associated with the virtualmachine, or an application characteristic of an application associatedwith the virtual machine.
 8. The method of claim 1, further comprising:partitioning, by the system, network addresses into respective groups ofnetwork addresses, comprising the group of network addresses, based onrespective characteristics associated with respective applicationsassociated with respective network nodes, comprising the network node,wherein the respective groups of network addresses are associated withthe respective classifications; and classifying, by the system, thenetwork node as being associated with the classification that isassociated with the group of network addresses based on a result ofcomparing the flow size associated with the network node to respectivethreshold flow sizes associated with the respective classifications. 9.The method of claim 1, wherein the group of network addresses comprisesnetwork addresses in a consecutive address order.
 10. The method ofclaim 1, wherein a function is applied to respective characteristics,comprising the characteristic, to facilitate estimating respective flowsizes, comprising the flow size, associated with respective networknodes, comprising the network node, and wherein the method furthercomprises: analyzing, by the system, the respective flow sizes andrespective actual flow sizes associated with the respective networknodes; determining, by the system, an amount of an error between therespective flow sizes and the respective actual flow sizes; andadaptively modifying, by the system, the function to generate a modifiedfunction, based on the amount of the error, to mitigate the amount ofthe error.
 11. The method of claim 1, wherein the network node is avirtual machine, and wherein the method further comprises: estimating,by the system, performance metrics associated with virtual machines,comprising the virtual machine, based on characteristics, comprising thecharacteristic, associated with the virtual machines; and determining,by the system, a placement of the virtual machine for a launching of thevirtual machine by a server based on the flow size of the virtualmachine, the performance metrics associated with the virtual machine,and resources of the server that are available to support an applicationassociated with the virtual machine.
 12. The method of claim 1, furthercomprising: detecting, by the system, a deviation from the flow sizeassociated with the network node during a defined time period;determining, by the system, whether an amount of the deviation satisfiesa defined threshold amount of deviation; and in response to determiningthat the amount of the deviation satisfies the defined threshold amountof deviation, determining, by the system, that a defined anomaly hasoccurred with respect to a network associated with the network node,wherein the defined anomaly is an attack on the network or a networkanomaly relating to a service failure associated with the network.
 13. Asystem, comprising: a processor; and a memory that stores executableinstructions that, when executed by the processor, facilitateperformance of operations, comprising: determining a flow sizeassociated with a network node based on an attribute associated with thenetwork node; and based on the flow size, determining, from a group ofnetwork addresses associated with a classification relating to a rangeof flow sizes, a network address that is to be assigned to the networknode.
 14. The system of claim 13, wherein the operations furthercomprise: predicting the flow size associated with the network nodebased on the attribute associated with the network node, wherein thedetermining the flow size associated with the network node comprisesdetermining the flow size associated with the network node based on thepredicting of the flow size associated with the network node.
 15. Thesystem of claim 14, wherein the network node is a virtual machine, andwherein the attribute comprises a flavor size, a number of virtualcentral processing units, a memory size, a disk space, a communicationbandwidth factor, a swap space, a first amount of volume storage, asecond amount of block storage, a server-related attribute associatedwith a server, a hypervisor-related attribute associated with ahypervisor, or an application-related attribute associated with anapplication executable by the virtual machine.
 16. The system of claim13, wherein the network address is an Internet protocol address or amedia access control address.
 17. The system of claim 13, wherein theoperations further comprise: partitioning network addresses intorespective groups of network addresses, comprising the group of networkaddresses, based on respective application-related attributes associatedwith respective applications associated with respective network nodes,comprising the network node, wherein the respective groups of networkaddresses are associated with respective classifications relating torespective ranges of flow sizes, wherein the respective classificationscomprise the classification, and wherein the respective ranges of flowsizes comprise the range of flow sizes; and determining that the networknode is associated with the classification that is associated with thegroup of network addresses based on a result of evaluating the flow sizeassociated with the network node and respective threshold flow sizesassociated with the respective classifications.
 18. The system of claim13, wherein the operations further comprise: determining first datatraffic processing rules that are determined to be able to provide firstflow-aggregated measurements that facilitate first estimations of flowsizes associated with respective network nodes with a first accuracythat is higher than a second accuracy of second estimations of the flowsizes associated with the respective network nodes that are able to beobtained from second flow-aggregated measurements using second datatraffic processing rules; and facilitating application of the first datatraffic processing rules to facilitate enhanced accuracy in furtherestimations of the flow sizes associated with the network nodes.
 19. Anon-transitory machine-readable medium, comprising executableinstructions that, when executed by a processor, facilitate performanceof operations, comprising: determining a flow amount associated with anetwork node based on a characteristic associated with the network node;and based on the flow amount, assigning, from a group of networkaddresses associated with a classification that is associated with arange of flow amounts, a network address to the network node.
 20. Thenon-transitory machine-readable medium of claim 19, wherein theoperations further comprise: partitioning network addresses intorespective groups of network addresses, comprising the group of networkaddresses, based on respective attributes associated with respectiveapplications associated with respective network nodes, comprising thenetwork node, wherein the respective groups of network addresses areassociated with respective classifications that are associated withrespective ranges of flow amounts, wherein the respectiveclassifications comprise the classification, and wherein the respectiveranges of flow amounts comprise the range of flow amounts; anddetermining that the network node is associated with the classificationthat is associated with the group of network addresses based on a resultof comparing the flow amount associated with the network node torespective threshold flow amounts associated with the respectiveclassifications.